search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.11k stars 4.97k forks source link

WLAN driver not working correctly when using HiFiBerry DAC+ Pro #1588

Closed hifiberry closed 7 years ago

hifiberry commented 8 years ago

When using the HiFiBerry DAC+ Pro, WLAN on the RPI3 isn't working anymore. The WLAN driver loads, the wlan0 interface is available, but no network connection is possible. External USB WLAN sticks work fine.

The problem occurs only with the DAC+ Pro, but not with any of our other sound cards. As main difference of the DAC+ Pro and the other sound cards is the clock driver (DAC+ Pro is using a clock driver, but the other cards aren't), it might be a problem with the clock driver selection of the onboard WLAN driver.

The DAC+ Pro itself is working fine.

Config.txt: dtoverlay=hifiberry-dacplus

Let me know how we can support you with this. You will need a DAC+ Pro as the clock driver isn't used with the DAC+ standard.

While I'm pretty sure that this was working when the RPI3 was released, even downgrading the kernel using rpi-update doesn't seem to fix the issue.

pelwell commented 8 years ago

Without looking at any of the code, I'd say having a DAC+ Pro might help. Alternatively, we could feed you patches with added diagnostics until we work out what is going wrong.

It would also help if you can find an old Raspbian release for which this problem didn't exist.

hifiberry commented 8 years ago

Hi Phil, sending you a DAC+ Pro isn't a problem at all. Can you just send me a message with your shipping address? I was looking for an older Raspbian release, but unfortunately I couldn't find an older version that was working. Is there any chance to find a Raspbian release from March somewhere? I don't have one on my computer anymore.

clivem commented 8 years ago

Daniel,

Now, my opinion about the outstanding BRCM wifi solution implemented on the Pi3B isn't a secret, and I disable it, in preference to using an external wifi solution, on all but one of my Pi3B boards.

Most curious, that the board that uses the on-board Pi3B wifi also happens to be the one that your DAC+ Pro is mounted to. Works for me! ;) (But I'm not using Raspbian. Kernel is latest rpi-4.4.y and userspace is Fedora 24.)

# uname -a
Linux BerryPlusPro3B1 4.4.16-503.20160807gite146e33.fc24.armv7hl.bcm2709 #1 SMP Sun Aug 7 06:41:10 BST 2016 armv7l armv7l armv7l GNU/Linux

# alsacap
Card 1, ID `sndrpihifiberry', name `snd_rpi_hifiberry_dacplus'
  Device 0, ID `HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0', name `', 1 subdevices (1 available)
    2 channels, sampling rate 8000..384000 Hz
    Sample formats: S16_LE, S24_LE, S32_LE
      Subdevice 0, name `subdevice #0'

# bcmstat iwlan0
  Config: v0.4.1, args "iwlan0", priority lowest (+19)
   Board: 4 x ARMv7 cores available, ondemand governor (Pi3 rev 1.2, BCM2837 SoC with 1GB RAM by Sony)
  Memory: 1008MB (split 992MB ARM, 16MB GPU) plus 286MB Swap
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  600MHz | 250MHz |   0MHz |    450MHz   |
Max Freq: | 1200MHz | 400MHz | 300MHz |    450MHz   |
Voltages: |         0, 1.3312V        | +1, 1.2250V |
   Other: temp_limit=85
Firmware: Jul 28 2016 12:43:29, version e12916091ba9d68ef2780e4e142ade56aa301754 (clean) (release)
  Codecs: none
  Booted: Sun Aug  7 14:59:12 2016

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s
======== ======= ======= ======= =============== ====== ========== ==========
15:05:00 1200Mhz  400Mhz  300Mhz 52.62C (52.62C)    207  2,420,195     72,605
15:05:02  600Mhz  250Mhz  250Mhz 51.54C (52.62C)    257  1,948,527     72,332
15:05:04  600Mhz  250Mhz  250Mhz 51.54C (52.62C)    258  1,766,814     55,657
15:05:06  600Mhz  250Mhz  250Mhz 51.00C (52.62C)    257  2,029,083     65,031
Peak Values: IRQ: 258, RX: 2420195, TX: 72605
hifiberry commented 8 years ago

@clivem , thanks for this feedback. This is becoming interesting. Any chance you can test it with Raspbian? I would not expect a bug in a user-level component, but otherwise I have no idea why it is working in your installation.

clivem commented 8 years ago

Any chance you can test it with Raspbian?

Sorry, won't have time today, but I'll try and see if I can re-produce the failure with a Raspbian image tomorrow.

hifiberry commented 8 years ago

No need to rush. Thanks for helping with this.

ghost commented 8 years ago

I had another look at the system logs. With the driver disabled, everything starts up fine, when the DAC+ Pro driver is used, I see this error message in the dmesg output:

[ 18.985289] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3) [ 18.985306] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

Does this help somehow?

juliusvaart commented 8 years ago

I'm using the Dac+ Pro on a RPI3 with Roon Bridge (https://roonlabs.com) and found out that sometimes i can get it to work, but the connection is destroyed immediately when playing a 48khz MP3 radio stream. 44.1khz MP3 radio streams and 44.1khz CD-quality FLAC files from Tidal don't invoke the behavior. Could it be the 48/96/192kHz clock?

ghost commented 8 years ago

@juliusvaart : This has nothing to do with this bug. I recommend to use the HiFiBerry Roon image and post your questions in the HiFiBerry support forum: https://support.hifiberry.com/hc/en-us/community/topics

juliusvaart commented 8 years ago

@usul27 : Tried the Roon-image, but using that i can't use the built-in WiFi at all and i can't debug for i can't SSH into the device (and i also want to use Airplay on the same device). Using Raspbian Jessie Lite i'm able to use WiFi with the Dac+ Pro and RPi3... just trying to say that the WiFi is working when playing 44.1khz files and all packets drop when playing 48khz. On a wired connection everything is working perfectly.

hifiberry commented 8 years ago

Ok, I'm a bit wiser now. It does not seem to be a kernel bug, but something else.

What doesn't work for me:

However, this one works:

So it seems, that there is a difference outside the Raspberry Pi kernel itself. I guess, there is a firmware for the WLAN chip. Maybe the problem comes from this software. Can someone point me to a file for this?

pelwell commented 8 years ago

Starting with Raspbian Lite (2015-05-10), adding the hifiberry-dacplus overlay and editing wpa_supplicant.conf works for me. My test clip is an mp3 ripped from a CD, so 44.1KHz.

pelwell commented 8 years ago

Yesterday's test was using mplayer to play an mp3, and sudo apt-get install mplayer pulled in a lot of dependencies. Today I've tried again using the standard aplay utility and a wav file, so apart from adding the dtoverlay line and the wpa_supplicant.conf this is an out-of-the box Raspbian Jessie Lite. Then I switched to the later 2016-05-27 release, with the same results - running aplay from an ssh shell connected over WiFi works as expected. Also, speaker-test works at 44.1, 48, 88.2, 96, 176.4 and 192KHz,

Perhaps there is a difference in AP configuration - channels, features - or that somehow causes this incompatibility?

ghost commented 8 years ago

Thanks for the test. This is becoming very interesting. Do you see the scan error in your dmesg output? [ 18.985306] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

pelwell commented 8 years ago

No, just the usual noise:

pi@raspberrypi:~ $ dmesg | grep brcmf
[    4.990674] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init done for chip 43430 rev 1 pmurev 24
[    4.991335] usbcore: registered new interface driver brcmfmac
[    5.111135] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[    5.136392] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[    6.243510] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[    6.243537] brcmfmac: brcmf_add_if: ignore IF event
[    6.248532] brcmfmac: power management disabled
titopoquito commented 8 years ago

First I had the same problem on SlackwareArm 14.2, not being able to use the Hifiberry DAC+ Pro and my internal wifi. After trying several mpd-focused distros I then helped myself by setting up a new SlackwareArm 14.2 system and using an USB soundcard. After reading the last comments I decided to try it again and guess what, now it is working nicely. As I am writing this, my Raspberry Pi 3 is playing using the Hifiberry DAC+ Pro and is connected over (the internal) wifi, too.

I'm starting my server in command line only (headless) mode. The wlan0 connection is managed by monit, configured to start the device with "nmcli connection up wlan0".

Since this system is different from Raspbian, feel free to ask me questions. SlackwareArm 14.2 is a softfloat port, btw, if that matters in troubleshooting.

EDIT: Fixed formatting.

dmesg output:

root@mrkicks:~# dmesg | grep brcmf
[    4.680697] usbcore: registered new interface driver brcmfmac
[    4.875817] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[    4.968053] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   22.422355] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[   22.422370] brcmfmac: brcmf_add_if: ignore IF event
[   22.426094] brcmfmac: power management disabled
[   22.901392] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[   22.901414] brcmfmac: brcmf_add_if: ignore IF even

Kernel is 4.4.19-v7

root@mrkicks:~# uname -a
Linux mrkicks 4.4.19-v7+ #906 SMP Tue Aug 23 15:53:06 BST 2016 armv7l BCM2709 GNU/Linux

I have not enabled the internal sound card:

root@mrkicks:~# LANG=en_US aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dacplus], device 0: HiFiBerry DAC+ Pro HiFi pcm512x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

wlan0 is up and running, just crossed out parts of mac address and IP:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.xxx.xx  netmask 255.255.255.0  broadcast 192.168.xxx.255
        inet6 fe80::ba27:ebff:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:xx:e4:xx  txqueuelen 1000  (Ethernet)
        RX packets 2040  bytes 194198 (189.6 KiB)
        RX errors 0  dropped 229  overruns 0  frame 0
        TX packets 950  bytes 238036 (232.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
kzkin commented 8 years ago

I'm using the Dac+ Pro on a RPI3 with Arch (https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3). Wifi doesn't work when dtoverlay=hifiberry-dacplus [root@alarmpi ~]# uname -a Linux alarmpi 4.4.21-1-ARCH #1 SMP Thu Sep 15 19:19:13 MDT 2016 armv7l GNU/Linux

pelwell commented 8 years ago

I was going to say that's very interesting (the bit about the slave mode working), but I see you've edited the comment. Does that mean it doesn't work in slave mode after all?

Can you upload the output of dmesg | brcmfmac when it fails?

Which WiFi channel does it use when it works (iwlist channel)? Have you tried changing the WiFi (if possible) to see if it works any better?

popcornmix commented 8 years ago

ITYM dmesg | grep brcmfmac

pelwell commented 8 years ago

Yes I did.

Hyperjett commented 7 years ago

Like juliusvaart i experienced the behaviour that the Wifi works only when 44.1kHz is being played. When 48kHz or multiples are played, it doesn't work:

A) I used Libreelec 7.90.008 ALPHA (Linux 4.8 kernel) -> wifi works from the start, but when a 48kHz (or multiple) file is played, it stops working. There is a workaround: i set audio sample rate to "fixed" and max. sample rate to 44.1kHz and wifi works all the time!

B) I used moode 2.7 with wifi Access Point (Linux kernel 4.4.19) -> I cannot connect to wifi AP after startup. It works only when i play a 44.1kHz file by wired connection. After that wifi works until i play a 48kHz (or multiple) file -> then wifi does not work any longer

pelwell commented 7 years ago

What do you mean by "moode 2.7"? Are you talking about the 2.4GHz band? Which particular channel is your AP on?

The DAC+ Pro and the WiFi device are interacting in a way which depends on the sample rate. A higher sample rate means a higher data throughput, so more interrupts and memory bandwidth, but that is true for any sound card; so far, only the DAC+ Pro has been observed to have a problem. The difference between the DAC+ Pro and many other cards is that it has its own low-jitter clocks. In order to cope with multiples of 44.1KHz and 48KHz it has two crystals and selects the appropriate one for the current stream. The crystals are switched on demand, but in the gaps between streams the previous crystal remains active. The fact that playing any 44.1KHz clip is enough to fix the problem until a 48KHz track is played suggests that the crystals are at the root of the problem since no audio data is being transferred in those gaps.

The I2S audio interface is serial, and sending 16-bit stereo at 44.1KHz requires a clock rate of 1.411GHz. At 48KHz that becomes 1.536GHz. For greater bit-depths you can double those numbers. None of those frequencies is in the 2.4GHz range, but 1.536*(3/2) is close, and sometimes it is a harmonic that interferes rather than the fundamental. Also, the crystals could be a multiple of these and I don't have a DAC+ Pro to hand right now to check... ah, there are some helpful constants in the driver:

/* Clock rate of CLK44EN attached to GPIO6 pin */
#define CLK_44EN_RATE 22579200UL
/* Clock rate of CLK48EN attached to GPIO3 pin */
#define CLK_48EN_RATE 24576000UL

2.457GHz is WiFi channel 10, which adds weight to my theory, but it is still just a theory - I'm only a software engineer, and you'd need to book time in an EMC test facility to properly analyse the problem - but I haven't heard any alternatives. It would be interesting to see if changing the AP channel can get it working with 48KHz material - I'd start with channel 1 and work upwards. You may be able to map out the problematic channels and see how severe the interference is.

clivem commented 7 years ago

What do you mean by "moode 2.7"? Are you talking about the 2.4GHz band?

Erm... I think he is talking about version 2.7 of the Moode OS distribution, rather than wifi frequencies.

pelwell commented 7 years ago

Ta - I haven't come across it before, and the lack of a capital threw me.

clivem commented 7 years ago

http://moodeaudio.org/ It's an audio OS for Pi, descended from VolumIO, (which I think is based on Raspbian), by a chap called Tim Curtis. It seems to be gaining popularity with the audiophools.....

clivem commented 7 years ago

NB.I never got around to testing with Raspbian..... But as I said before the HB DAC+ Pro worked for me, in master mode, on Pi3B, using on-board wifi.... (And when I say it worked, I mean at all sample rates 44k1-384k, all 44k1 and 48k multiples..... music being streamed over BRCM wifi connection. Sorry, don't have any time to put into helping investigating this, at the moment.)

Hyperjett commented 7 years ago

Ok, sorry, it is moOde Audio V.2.7 http://moodeaudio.org/

I did some more tests with moOde Audio: AP Channels which never worked with 48kHz playback were: Ch1, Ch2, Ch6, Ch11. But i think they all worked with 44.1kHz (not 100% sure if i checked all for 44.1).

The other channels 3,4,5,7,8,9,10 worked with 48kHz (and 44.1kHz), but some had a bad connection when playing 48kHz (4 was not very reliable, but 10 was very good for example. I then chose 10. The default of MoOde is Channel 6, which doesnt work with 48kHz).

My LibreElec v7.90.008 ALPHA (https://libreelec.tv/) is using my wifi router, which is fixed on Channel 1. There 48kHz also doesnt work.

I hope this helps...

pelwell commented 7 years ago

Thanks for the detailed report. Since the WiFi channels have the same bandwidth, the only part of the system that changes with channel number is the frequency band occupied. If, as you suspect, all the channels worked with 44.1kHz, then the evidence is pointing towards an EMC issue, either through the air to the antenna or conducted through the header pins.

The list of good vs bad channels isn't quite what I expected, but that could be down to signal-to-noise ratios; the problematic channels are also the most common channels, and therefore the ones most likely to be congested, so perhaps any additional interference is more likely to make the channel unusable. Plus, the inverse square law means a whisper in your ear can drown out a jet aeroplane overhead.

hifiberry commented 7 years ago

@Hyperjett If this is an EMV issue, we should will need to fix this in hardware. Can you please get in touch with us at support@hifiberry.com We might need to test an updated board design.

hifiberry commented 7 years ago

And an update from our side here: We have reports that fixing the WLAN access point to use a specific channel fixes this problem. This seems to work on any channel. Therefore it looks like this isn't an EMI issue, but rather a problem when the WLAN channel switches. @Hyperjett did you fix the channel in your tests?

Hyperjett commented 7 years ago

Yes, i used fixed channels. And my WLAN Access Point with fixed channel 1 did not work with 48kHz. Now i switched my Access Point to fixed Channel 5 and it works perfectly with 44.1 and 48kHz. I never used auto channel, only fixed.

avian2 commented 7 years ago

We encountered this same problem. Internal Raspberry Pi 3 wireless adapter loses connection to AP when HiFiBerry DAC+ pro is used. External USB dongle works fine when connected over an extension cable and placed some distance away from the board. We used the Volumio SD card image (we don't know what playback sample rate was used).

We did some measurements with a spectrum analyzer and a simple near-field probe. It appears that the crystal oscillators on the HiFiBerry are emitting a lot of interference over a wide spectrum. In the 2.4 GHz band we saw emission spikes that correspond roughly with center frequencies of Wi-Fi channels 1, 6, 11 and 14.

More details and spectrum analyzer screenshots are in this blog post.

pelwell commented 7 years ago

Thanks for the detailed analysis - it looks like you had fun. My comment about possible I2S harmonics was early speculation before discovering the crystal frequencies - it's good to have some real world measurements.

hifiberry commented 7 years ago

@avian2 Thanks for this. We're testing a version with additional LP filtering. I hope to have a prototype here soon.

Thijs-Rallye commented 7 years ago

Interesting thread. I experience problems as well when playing 48 kHz mp3's on a RPi 2 and HiFiBerry DAC+ Pro with an external wifi dongle. Could this be related? In my case it plays a few seconds, starts to get choppy and then the whole UI stops responding and I cannot access the device via SSH anymore. TTY1 stays responsive though. Could this be related? (Volumio 2)

pelwell commented 7 years ago

If you can, try using WiFi channel 10 instead and see if that makes a difference.

Thijs-Rallye commented 7 years ago

I've just gave it a go: I've set my WiFi router at channel 10 and now it works like a charm! It was previously (automatically) set at channel 11, which I've read here above was also one of the scrambled frequencies.

Thanks for the suggestion, at least I can enjoy my whole music collection now :). But I assume there will be some kind of permanent fix for this?

Edit: I forgot to thank pelwell! Thanks!!!

hifiberry commented 7 years ago

We will test a new hardware release soon. Contact me at support@hifiberry.com. We will send you one of the test boards when we have them here.

JoergZ2 commented 7 years ago

Maybe that the WiFi problem is independent from hifiberry. I'd had a lot of problems with wifi access until I added this line at the end of the file /etc/ssh/sshd_conf IPQoS 0x00 especially problems with the SSH access. Problems with MPD were gone after I changed the line After=network.target sound.target to After=network.target sound.target alsa-restore.service in the file /lib/systemd/system/mpd.service. Do both actions as root. Maybe it helps.

EDIT: My mistake: It works only with a USB-WiFi Dongle NOT with the internal WiFi

EDIT 2: Changing to channel 10 solved the problem. Now it works with the internal WiFi only.

pelwell commented 7 years ago

I think we're fairly certain that this particular issue is caused by an EMC problem.

hifiberry commented 7 years ago

I can confirm this. We've tested some new oscillators that fix this. If somebody has problems with the DAC+ Pro, please contact us directly at support@hifiberry.com

hifiberry commented 7 years ago

I think, we can close this bug.

Ruganer commented 6 years ago

... same with the Adafruit Stereo Speaker Bonnet. W-LAN on Raspi3 not working. Works with external USB-WIFI. https://cdn-learn.adafruit.com/downloads/pdf/adafruit-speaker-bonnet-for-raspberry-pi.pdf

pelwell commented 6 years ago

Try setting your WiFi AP to channel 10 and see if it makes a difference.

anarkiwi commented 2 years ago

I hope this will save some others, this trouble. On multiple Zero 2W's, with a hifiberry-dacplusadcpro installed, kernel 5.10.92-v7+, WiFi is nearly unusable (no matter what the channel) due to packet loss.

Installing a layer of insulation tape and then aluminium tape (I used 3M, I assume others will work just as well - see attached) works around the issue. Separating the Zero 2W from the hat using a ribbon cable, also works.

tape pi