PDA

View Full Version : PiCoreplayer+Jivelite Sound Issue



Just_Colin
2017-05-29, 06:02
Hello,

I use PiCorePlayer 3.20 on a Pi2 + 7” Touchscreen Display, with a Woo WA7 as USB DAC. This plays perfectly glitch-free up to 24/192 except when I enable Jivelite, then i get audio "pops" every few seconds even with 16/48 files. When I disable Jivelite and reboot all is perfect again.

Squeezelite settings are OUTPUT="front:CARD=WooAudio,DEV=0", ALSA_PARAMS="80:4::1:". Everything else is standard. LMS is running on a QNAP NAS.


cat /proc/asound/cards
0 [ALSA ]: bcm2835 - bcm2835 ALSA
bcm2835 ALSA
1 [WooAudio ]: USB-Audio - WooAudio
XMOS WooAudio at usb-3f980000.usb-1.4, high speed


Any idea why this is, or what I can do to fault-find it?
:confused:

ralphy
2017-05-30, 04:30
Hello,

I use PiCorePlayer 3.20 on a Pi2 + 7 Touchscreen Display, with a Woo WA7 as USB DAC. This plays perfectly glitch-free up to 24/192 except when I enable Jivelite, then i get audio "pops" every few seconds even with 16/48 files. When I disable Jivelite and reboot all is perfect again.

Squeezelite settings are OUTPUT="front:CARD=WooAudio,DEV=0", ALSA_PARAMS="80:4::1:". Everything else is standard. LMS is running on a QNAP NAS.


cat /proc/asound/cards
0 [ALSA ]: bcm2835 - bcm2835 ALSA
bcm2835 ALSA
1 [WooAudio ]: USB-Audio - WooAudio
XMOS WooAudio at usb-3f980000.usb-1.4, high speed


Any idea why this is, or what I can do to fault-find it?
:confused:

Try changing the front: to hw: for the output device.

hw:CARD=WooAudio,DEV=0

Also there are USB driver options you can change on the tweaks webgui page which may help.

22799

Just_Colin
2017-05-30, 11:41
Try changing the front: to hw: for the output device.

hw:CARD=WooAudio,DEV=0

Also there are USB driver options you can change on the tweaks webgui page which may help.

22799

The problem is still there when I set the output to hw:CARD=WooAudio,DEV=0

If I set dwc_otg.speed=1 there is no sound whatsoever. LMS and Squeezelite/Jivelite thinks a track is playing, but if I look at /proc/asound/WooAudio/stream0 it says "Status: Stop" and there are no stream parameters.

Selecting Disable USB-FSM does not eliminate the problem.

I tried all of the FIQ_FSM USB settings but all had the problem.

What became clear to me during testing though was the problem was worse when the display was on "Now Playing" showing the artwork and scrolling text, rather than just the main menu.

The standard setting is for Squeezelite to run at a higher priority, but using htop only one of four squeezelite processes has a non-standard priority;

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2367 root 20 0 13336 10372 3988 S 0.8 1.1 0:11.91 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
2388 root -46 0 13336 10372 3988 S 0.8 1.1 0:05.21 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
3127 root 20 0 36616 24660 2928 S 1.2 2.6 0:22.26 /opt/jivelite/bin/jivelite
2373 root 20 0 13336 10372 3988 S 0.0 1.1 0:00.85 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
5136 root 20 0 4740 2924 2680 S 0.0 0.3 0:00.29 sshd: tc@pts/0
2462 root 20 0 13336 10372 3988 S 0.0 1.1 0:05.63 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v

Is there a reason jivelite isn't run as a lower priority?

Any other suggestions?

ralphy
2017-05-31, 05:32
That's right, only the output thread sets the higher priority.

We've never had a reason to run jivelite at a lower priority. You can try using renice on the jivelite process to lower it's priority.

I tried to reproduce your issues on a rpi b+, not overclocked, usb wireless, a 48/16 usb dac and the official rpi screen and squeezelite played fine with jivelite running but it's not the same dac.

You could also try using the rpi built in audio just to test if you have the same issue as your usb dac.

Just_Colin
2017-05-31, 10:13
That's right, only the output thread sets the higher priority.

We've never had a reason to run jivelite at a lower priority. You can try using renice on the jivelite process to lower it's priority.

I tried to reproduce your issues on a rpi b+, not overclocked, usb wireless, a 48/16 usb dac and the official rpi screen and squeezelite played fine with jivelite running but it's not the same dac.

You could also try using the rpi built in audio just to test if you have the same issue as your usb dac.

I reniced the two jivelite processes (only one seems to be doing much, the other is always bottom of the CPU activity) to +19, but still have the same issue.


1 [ 0.0%] Tasks: 15, 4 thr; 1 running
2 [||| 2.8%] Load average: 0.09 0.09 0.06
3 [||| 3.3%] Uptime: 00:10:19
4 [||| 2.6%]
Mem[||||||||||||| 111M/939M]
Swp[ 0K/227M]

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
3342 root 39 19 68812 57088 3332 S 8.9 5.9 1:08.95 /opt/jivelite/bin/jivelite
2501 root 20 0 13336 10372 3988 S 4.1 1.1 0:25.96 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
2590 root 20 0 13336 10372 3988 S 4.1 1.1 0:17.64 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
4975 root 20 0 3312 2416 1816 R 2.7 0.3 0:12.38 htop
2527 root -46 0 13336 10372 3988 S 0.7 1.1 0:05.93 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v
4944 root 20 0 4740 2828 2584 S 0.7 0.3 0:00.40 sshd: tc@pts/0
2512 root 20 0 13336 10372 3988 S 0.0 1.1 0:02.13 /usr/local/bin/squeezelite -n piCorePlayer -o hw:CARD=WooAudio,DEV=0 -a 80 4 1 -p 45 -v

I don't have the issue when I change to Analog output.

I definitely hear a correlation between screen animation and this problem. I have the Screensaver set to Now Playing when a track is playing, and cycling through them, the effect seems less with just the artwork alone showing. With the screensaver set to Blank, the problem is gone (or very rare, I need more listening time to be sure).

Jivelite runs up to 10-12% CPU (according to htop) when showing the Now Playing screensaver, and generally cpu usage seems fairly low.

I'll try with a couple of other DACs at the weekend to see either have the same issue.

steff
2017-06-01, 15:25
Hello,

I use PiCorePlayer 3.20 on a Pi2 + 7 Touchscreen Display, with a Woo WA7 as USB DAC. This plays perfectly glitch-free up to 24/192 except when I enable Jivelite, then i get audio "pops" every few seconds even with 16/48 files. When I disable Jivelite and reboot all is perfect again.




This is the VERY same problem I am facing since the LCD touch has been added.

I have an USB DAC M2tech that is absolutely perfect up to 384 khz with the very same raspberry Pi3 and pure MPD
I even tried a Teac USB DAC... same problems.

sbp
2017-06-01, 21:26
Hi, as most of our users don't have this problem we at the pCP team haven't seen it either, there must be something special with your setup.
could it be a power issue? Do you see a lightning bolt when booting? Could you try another more powerful PSU?

steff
2017-06-02, 13:07
Hi, as most of our users don't have this problem we at the pCP team haven't seen it either, there must be something special with your setup.
could it be a power issue? Do you see a lightning bolt when booting? Could you try another more powerful PSU?

No, I do not see any lighting bolt when booting or during the normal use.
in order to see this bolt, I have to switch to a low power old microUSB power supplier and connect it to the LCD board and not on the Rpi3 mainboard.
I have a dozen of power suppliers, I tested all of them, no improvement.
The one I am using right now is the official Raspberry 2.5 A. I plugged a digital sampling Fluke multimeter (a 600 $ unit) to see if I have any drops in the voltage, but... sorry... no drops at all (2ms sampling interval)

More over, I eneabled the local LMS and disabled both wired Eth and WiFI and play the FLAC from a local USB memory: same results.

I will appreciate a lot any suggestion.
I can collaborate actively in collecting logs or other info...

thanks

M-H
2017-06-02, 14:37
Perhaps you can try a bit more buffering in the squeezelite output.
I had similar output issues in the past , before using i2s soundcards and pcp.
So change ALSA_PARAMS="80:4::1:" to ALSA_PARAMS="160:4::1:" and see if it helps.
Greetz M-H

steff
2017-06-02, 16:12
Perhaps you can try a bit more buffering in the squeezelite output.
I had similar output issues in the past , before using i2s soundcards and pcp.
So change ALSA_PARAMS="80:4::1:" to ALSA_PARAMS="160:4::1:" and see if it helps.
Greetz M-H

Yes, I already played with the buffer settings, without any improvement.

More over, just made another test:
the LCD board of the raspberry gets power from the raspberry main board. I powered the mainboard and the LCD with two separate power supplier ( 2.5 A each ), but no improvement.

it is for sure something related to the LCD, but... having the LCD connected but Jivelite not installed (so, in the LCD you have just the kernel consolle) the sound is perfect.
Installing Jivelite, but keeping it off, again is perfect.
Enebling Jivelite... nightmare.

it is not a problem of power, of network (same problem playing from USB memory), of the DAC, and so on... it a problem of the graphic interface & high res file (no problem @ 44 kHz)

sbp
2017-06-02, 22:19
Both of you are using a USB DAC, I noticed there have been some improvements in how raspberry kernel handle USB output, I hope your issue will be fixed when we release a new version based on the new kernel.

In the meantime, have you tried to overclock your raspberry?

Just_Colin
2017-06-03, 06:56
Just tested with two other USB DACs;

Audiolab M-DAC - no sound glitches noticed
Audioengine D1 - some glitches heard but not as bad as WooAudio DAC

Back to the WooAudio, I doubled the buffer time but that had no effect. I tried different and separate power supplies but no difference. There is no option to overclock with the pi2.

I do see this boot message with the WooAudio;

Starting ALSA configuration... alsactl: set_control:1461: Cannot write control '2:0:0:XMOS Internal Clock Validity:0' : Operation not permitted

I don't know if that has any bearing on it?

So my best bet ATM with the WooAudio DAC is to select Blank Screen during Now Playing, which seems to produce no glitches even with 24/192 streams.

M-H
2017-06-04, 04:00
There is no option to overclock with the pi2.


To my knowledge there are options to push the pi2 to higher performance;
https://haydenjames.io/raspberry-pi-2-overclock/
might help you . Or test with a pi3B if you have that option.

And reading al your tests to exclude possible causes, the transport of data towards the USB device could be your problem.
With high data rates, and relative slow transport you are easy to fall short in the buffering department.
I do experience this with synchronised wifi players and HD audio files. ( but no complaints, I know I am pushing into the known risk zone )
Playing the same audio in the same set of players but through MP3 does remove the issue.

Perhaps your WooAudio USB DAC has a bit less local buffering, and is more prone to this just not fast enough transport.
Jivelite might steal a few CPU cycles now and then during USB transport cycles, I am not sure.
Also transport to the display might interrupt other tasks....
But there are enough people here that can comment on my hypothese.

An other suggestion , while we wait on future further optimised USB routines, Test with audio files on the SD card.
Reading from Network or USB memory does need reads from usb and writes to usb devices, hence double USB transport.
It might support my hypotheses, and give us more insight.
And you could eliminate the LCD , and test jivelite over HDMI or Composite Video.

Greetz M-H

steff
2017-06-05, 02:39
To my knowledge there are options to push the pi2 to higher performance;
https://haydenjames.io/raspberry-pi-2-overclock/
might help you . Or test with a pi3B if you have that option.

And reading al your tests to exclude possible causes, the transport of data towards the USB device could be your problem.
With high data rates, and relative slow transport you are easy to fall short in the buffering department.
I do experience this with synchronised wifi players and HD audio files. ( but no complaints, I know I am pushing into the known risk zone )
Playing the same audio in the same set of players but through MP3 does remove the issue.

Perhaps your WooAudio USB DAC has a bit less local buffering, and is more prone to this just not fast enough transport.
Jivelite might steal a few CPU cycles now and then during USB transport cycles, I am not sure.
Also transport to the display might interrupt other tasks....
But there are enough people here that can comment on my hypothese.

An other suggestion , while we wait on future further optimised USB routines, Test with audio files on the SD card.
Reading from Network or USB memory does need reads from usb and writes to usb devices, hence double USB transport.
It might support my hypotheses, and give us more insight.
And you could eliminate the LCD , and test jivelite over HDMI or Composite Video.

Greetz M-H

I can confirm that using a Now Playing view with static obejects (for example just the cover art) and no scrolling text and no progressive playing bar and so on... things are a bit better... noise is reduced.
Moreover, I tested several FLAC, from 44 to 384 kHz and... what make the difference is the bitrate and not just the sampling rate.
Ler me explain: I have 384 kHz with 6 kbps VBR and with 11 kbps VBR...
@ 6 kbps it is noisy but much more less noisy than @ 11 kbps

For the CPU... let me say that it is not an issue: here my results:

Running Raspbian + pure MPD, the results are always PERFECT, absolutely but the CPU usage rise 30% in some cases.
Running Volumio (that is based on MPD) with no graphic interface it is perfect as above
Adding the graphic interface to Volumio... it is TERRIBLE and the CPU goes very very high
With piCorePlayer + Jivelite I experience noise, as told in this post, but the CPU is extremely LOW LOW LOW... never higher than 10% and the most consuming process is CIFSD responsible for mounting the SAMBA from the network.

Why Rpi3 + Raspbian + MPD is always perfect even with a much more high CPU usage?

Are there any tools or commands to check... let me say... interrupts, buffers and so on real time?

sbp
2017-06-05, 06:16
Have you tried both piCorePlayer versions, both the audio specific version with all the different tweaks we apply during building of the kernel as well as the more conservative build (normal) build?

steff
2017-06-05, 08:11
Have you tried both piCorePlayer versions, both the audio specific version with all the different tweaks we apply during building of the kernel as well as the more conservative build (normal) build?

No, I just tried the stadard version, since the Audio Optimized one was not suggested for USB DAC

This version contain all the same improvements as the above normal version. But in addition we have added all the audio related patches that Clive (aka JackOfAll) made for the raspberry kernel. So here we have support for more i2s-DACs and we support higher sample rates etc. **Please note: This version is only recommended for I2S soundcards and hardwired network. The optimizations for audio has been known to interfere with wifi, and for sure will make USB soundcards unstable.

sbp
2017-06-05, 09:02
You are absolutely fight, it was just to see if it did make a difference

steff
2017-06-05, 14:16
Just tested with two other USB DACs;

Audiolab M-DAC - no sound glitches noticed
Audioengine D1 - some glitches heard but not as bad as WooAudio DAC

Back to the WooAudio, I doubled the buffer time but that had no effect. I tried different and separate power supplies but no difference. There is no option to overclock with the pi2.

I do see this boot message with the WooAudio;

Starting ALSA configuration... alsactl: set_control:1461: Cannot write control '2:0:0:XMOS Internal Clock Validity:0' : Operation not permitted

I don't know if that has any bearing on it?

So my best bet ATM with the WooAudio DAC is to select Blank Screen during Now Playing, which seems to produce no glitches even with 24/192 streams.

Hi
DID you eventually tested the Audio Optimized version of piCorePlayer?
(I did not)

steff
2017-06-06, 02:51
You are absolutely fight, it was just to see if it did make a difference

I tried this morning.
brand new microSD, flashed 3.20 Audio Optimized, extended the file system, installed LMS and extensions, loaded Jivelite, etc.

using the very same audio output used with the 3.20 standard version, I was unable to play 352 kHz FLAC, no soud at all.
I had to set the IEC958 string.
with the standard version of 3.20 I used hw:CARD=M20,DEV=0

Anyway, even with the 3.20 Audio Optimized and IEC958 there is NO improvement at all.

Is there any logs I can look at in order to provide additional infos for the trobleshooting?

Just_Colin
2017-06-06, 09:33
Hi
DID you eventually tested the Audio Optimized version of piCorePlayer?
(I did not)

Just updated and chose the "Audio enthusiast version". Footer now says;
piCorePlayer | piCorePlayer v3.20 | linux 4.9.21-pcpAudioCore_v7 | piCore v8.01 | Squeezelite v1.8.6-957 | Tue Jun 6 17:26:59 BST 2017

Still the same issue as before...:(

I may try overclocking although the option is greyed out on the piCorePlayer web page, so I would have to try it manually :eek:

steff
2017-06-07, 05:13
You are absolutely fight, it was just to see if it did make a difference

Anyway, since it seems there is no solution "right out of the box", just to uinderstand:
- is it a matter of the Kernel?
- or about Squeeze
- or about ALSA

Any idea about how to find the source of the problem?

Just_Colin
2017-06-10, 04:07
I have just tried some Advance Overclock options.

First. I increased the GPU memory to 256 and rebooted. No improvement.

Then I set Overclock/underclock to High and rebooted. No improvement.

I then tried setting the Force turbo to Yes and rebooted. Massive improvement, I think the glitches are completely gone now! (but will need to do more listening to be sure).
:D

steff
2017-06-12, 08:05
I have just tried some Advance Overclock options.

First. I increased the GPU memory to 256 and rebooted. No improvement.

Then I set Overclock/underclock to High and rebooted. No improvement.

I then tried setting the Force turbo to Yes and rebooted. Massive improvement, I think the glitches are completely gone now! (but will need to do more listening to be sure).
:D

Will try this evening.
In the meanwhile, can you explain to me what is TURBO MODE for?

Just_Colin
2017-06-12, 09:51
Will try this evening.
In the meanwhile, can you explain to me what is TURBO MODE for?

I'm not sure to be honest. According to https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md it
"Forces turbo mode frequencies even when the ARM cores are not busy."

I don't know if it will have an impact on reliability though...

steff
2017-06-12, 14:59
Just_Colin

great first preliminary result!

I booted my Rpi3 with TURBO MODE enabled and now it seems that all my high resolution FLAC are played without any audible pops, glitches, scratches, etc.
I am listening right now some 352 kHz \ 24 bit and they seem perfect. :D

Anyway, I had to connect two power suppliers... with just one ( 2.5 A ) the lighting bolt is always on the corner of the screen and I have sporadic pops.

many many thanks for your suggestion!!!

how about your setup?

Jeff07971
2017-06-12, 15:34
I'm not sure to be honest. According to https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md it
"Forces turbo mode frequencies even when the ARM cores are not busy."

I don't know if it will have an impact on reliability though...

A good heatsink might be a good idea combined with good ventilation

Just_Colin
2017-06-13, 11:18
Anyway, I had to connect two power suppliers... with just one ( 2.5 A ) the lighting bolt is always on the corner of the screen and I have sporadic pops.

many many thanks for your suggestion!!!

how about your setup?

Mine seems OK on a single power connection (only just tried it), which ATM is connected to a Cheotech 50W 6-port which I think can provide up to 2.4A per port.

I don't know if running it with force_turbo=1 will have an effect on the reliability or lifetime, can anyone advise?

22894

A good heatsink might be a good idea combined with good ventilation

I don't use a case, as you can see it's mounted on the display and the stand has an open back, but I'll keep an eye on it.

sbp
2017-06-13, 12:04
Glad to hear that you tried overclocking and it solved the problem.
I don't think turbo mode will affect lifetime - I have used it for years on one of my RPi's and haven't seen any issue.

When we release a new version you could try to remove the overclock settings as there might be improvements in the kernel that could resolve your issue.

steff
2017-06-15, 01:15
I can confirm, after two days of test, all the noise disappeared! even at the highest bitrate (352 kHz and 11 Mbps).

Moreover, in the past, it was NOT possible to use the Rpi3 built-in WiFi with high res FLAC, now with TURBO MODE enabled, I can play from the network files up to 192 kHz.
Files @ 352 kHz... sorry... still no way with built in wifi.
Anyway it is a very big improvement.

Question: buying an additional USB WiFi adapter, maybe @ 5 Ghz, will produce improvements?
What is a raccomendation for a good adapter accordiong to you?

steff
2017-08-02, 15:55
As suggested I tried 3.21 and the behaviour it the very same as 3.20

I still need to force TurboMode to avoid drops at high bitrate.

paul-
2017-08-02, 16:50
Sorry I didn't see this but the Edimax EW-7811UTC AC600 is supported in pCP. I use this adapter. My router is an Netgear Nighthawk x4s r7800 whichi is AC2600

iperf3 results
From a rpi2B+ with the EW-7811UTC connected at 5Ghz ......iperf3 server is a hardwired intel GB adapter.....Quad Core i7.


Connecting to host 192.168.0.141, port 5201
[ 4] local 192.168.0.27 port 54850 connected to 192.168.0.141 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 25.3 MBytes 212 Mbits/sec 0 485 KBytes
[ 4] 1.00-2.00 sec 28.0 MBytes 234 Mbits/sec 0 592 KBytes
[ 4] 2.00-3.00 sec 26.6 MBytes 223 Mbits/sec 0 592 KBytes
[ 4] 3.00-4.00 sec 27.9 MBytes 234 Mbits/sec 0 624 KBytes
[ 4] 4.00-5.00 sec 28.6 MBytes 240 Mbits/sec 0 624 KBytes
[ 4] 5.00-6.00 sec 27.5 MBytes 230 Mbits/sec 0 624 KBytes
[ 4] 6.00-7.00 sec 27.6 MBytes 232 Mbits/sec 0 624 KBytes
[ 4] 7.00-8.00 sec 28.1 MBytes 235 Mbits/sec 0 649 KBytes
[ 4] 8.00-9.00 sec 28.4 MBytes 237 Mbits/sec 0 718 KBytes
[ 4] 9.00-10.00 sec 27.7 MBytes 233 Mbits/sec 0 718 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 275 MBytes 231 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 275 MBytes 230 Mbits/sec receiver


This is the iperf data from the same rpi ethernet port.....


Connecting to host 192.168.0.141, port 5201
[ 4] local 192.168.0.32 port 57312 connected to 192.168.0.141 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 11.3 MBytes 94.5 Mbits/sec 0 26.9 KBytes
[ 4] 1.00-2.00 sec 11.2 MBytes 94.2 Mbits/sec 0 28.3 KBytes
[ 4] 2.00-3.00 sec 11.2 MBytes 94.2 Mbits/sec 0 28.3 KBytes
[ 4] 3.00-4.00 sec 11.2 MBytes 94.3 Mbits/sec 0 39.6 KBytes
[ 4] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec 0 39.6 KBytes
[ 4] 5.00-6.00 sec 11.2 MBytes 94.1 Mbits/sec 1 26.9 KBytes
[ 4] 6.00-7.00 sec 11.2 MBytes 94.1 Mbits/sec 0 26.9 KBytes
[ 4] 7.00-8.00 sec 11.2 MBytes 94.0 Mbits/sec 0 26.9 KBytes
[ 4] 8.00-9.00 sec 11.2 MBytes 94.3 Mbits/sec 0 41.0 KBytes
[ 4] 9.00-10.00 sec 11.2 MBytes 94.2 Mbits/sec 0 41.0 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec 1 sender
[ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec receiver


So at least in a quick short test the wifi stick has much more bandwidth than even the hard wired connection......I have seen similar results with using a hardwired USB Gigiabit adapter. This was with no other activity on the USB ports. Remember on a rpi3, all network (even hardwared) uses the onboard USB chipset.

steff
2017-09-19, 02:20
Sorry I didn't see this but the Edimax EW-7811UTC AC600 is supported in pCP. I use this adapter. My router is an Netgear Nighthawk x4s r7800 whichi is AC2600


need your help.
Since I was looking for a better WiFi than the Rpi3 built-in WiFi, I just got the very same adapter... the 7811utc.
I tested it in advance on a PC and it work very well, then i connected it to the Rpi3
According to the messages on the console, it is recognized, but... I can not ave it working.

Try to explain: in the piCore config web page for the WiFi, there are two main switches: WiFi on\off and Rpi3 embedded WiFi on\off.
I switch the poor embedded off, reboot, then the Rpi3 connects to the WiFi AGAIN with the ebedded.
Seems that the on\off switch for the embedded takes no effect at all and moreover the Edimax does not want to connect.

Can you help me, please?

Jeff07971
2017-09-19, 02:23
need your help.
Since I was looking for a better WiFi than the Rpi3 built-in WiFi, I just got the very same adapter... the 7811utc.
I tested it in advance on a PC and it work very well, then i connected it to the Rpi3
According to the messages on the console, it is recognized, but... I can not ave it working.

Try to explain: in the piCore config web page for the WiFi, there are two main switches: WiFi on\off and Rpi3 embedded WiFi on\off.
I switch the poor embedded off, reboot, then the Rpi3 connects to the WiFi AGAIN with the ebedded.
Seems that the on\off switch for the embedded takes no effect at all and moreover the Edimax does not want to connect.

Can you help me, please?

Did you hit "Save/Connect" after setting Built in wifi off ?

steff
2017-09-19, 02:48
Did you hit "Save/Connect" after setting Built in wifi off ?

SURE

It seems that there is something not very clear to me aroud networking.

In the past I worked hours on another annoying problem: using the embedded WiFi, it was working only if the Eth wired was connected at the same time...
having the wired connected, then the WiFi was OK (useless), unplugging the wired (and rebooted), the WiFI stopped.
It is solved but I really do not understand why. and,.. I am playing aroud Reasperries since the very beginning.

Maybe in the piCore there are commands that must be executed in the proper way... let me say... save here, no reboot, save there reboot... is not good... but we must do save here, reboot, save there, reboot...

Jeff07971
2017-09-19, 02:51
Maybe in the piCore there are commands that must be executed in the proper way... let me say... save here, no reboot, save there reboot... is not good... but we must do save here, reboot, save there, reboot...

You may have a point there, I remember having something like this problem but a long time ago now. I think its best that if the Pi says reboot you do, it dosent take very long

Greg Erskine
2017-09-19, 05:37
There a multiple layers to this issue.

You have to remember piCore is a extremely small embedded Linux in RAM. This means every time you reboot, unlike normal Linux installations, you get a brand new, fresh Linux install from source. Also, what installs into RAM depends on what options you have selected. For example, if you aren't using wifi, the wifi extensions will not be loaded. When you have enabled wifi, the extensions are loaded during the boot process. If you disable wifi, the wifi extensions are still loaded in memory until the next boot.

So, by default, this means when you delete an extension in piCore, it marks the extension and its dependencies to not load during the boot process, it doesn't delete them dynamically.

We occasionally, change this default behavior but it sometimes causes us grief.

If the option you selected modifies the Raspberry Pi configuration file it usually is not activated until the next boot.

If the option you selected is an squeezelite option, then restarting squeezelite is usually sufficient.

You also need to assume that hot swapping USB devices doesn't work.

As far as networking is concerned, squeezelite will use wired ethernet over wifi, so if you happen to have both activated squeezelite will used wired Ethernet but you can use either for the web interface. Remember when playing around the IP address usually changes going from wired to wifi.

When the reboot screen pops up in piCorePlayer it usually means a backup has been done and a reboot is required to activate the change. If you are doing multiple changes and know what you are doing, you can delay the reboot until the next option has been set. Rebooting will then activate both changes.

regards
Greg

steff
2017-09-19, 15:25
Got it
Seems that before configuring the USB stick I have to disable the built in WiFi and reboot, then configure the USB.
Doing this way and rebooting the Rpi3 every time it is asked and avoiding cumulate changes before rebooting, the USB WiFi stick now works.

This Edimax 7811utc is great!
Now I can connect to the nwtwork and play high resolution files, even 384 KHz\24 bit without any audible pops!!! (of course I had to enable the TURBO mode).

GREAT !