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

Comments

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.

This comment has been minimized.

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.

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.

This comment has been minimized.

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.)

edited

Edited 1 time

clivem edited Aug 7, 2016 (most recent)

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.)

This comment has been minimized.

@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 ,
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.

This comment has been minimized.

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?

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?

This comment has been minimized.

@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.

edited

Edited 1 time

juliusvaart edited Aug 30, 2016 (most recent)

@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.

put it back into an RPI3, configure WLAN by hand (for whaterever reason, WLAN config via interfaces file was not working here)

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?

put it back into an RPI3, configure WLAN by hand (for whaterever reason, WLAN config via interfaces file was not working here)

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?

This comment has been minimized.

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?

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?

This comment has been minimized.

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.

edited

Edited 1 time

titopoquito edited Sep 6, 2016 (most recent)

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.

This comment has been minimized.

This comment has been minimized.

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

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

This comment has been minimized.

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:

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.

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:

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.

This comment has been minimized.

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.)

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.)

This comment has been minimized.

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.

edited

Edited 1 time

Hyperjett edited Nov 14, 2016 (most recent)

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...

This comment has been minimized.

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.

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.

This comment has been minimized.

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?

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?

This comment has been minimized.

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.

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.

This comment has been minimized.

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.

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.

This comment has been minimized.

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.

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.

This comment has been minimized.

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)

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)

This comment has been minimized.

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?

edited

Edited 1 time

Thijs-Rallye edited Dec 2, 2016 (most recent)

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?

This comment has been minimized.

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_confIPQoS 0x00
especially problems with the SSH access.
Problems with MPD were gone after I changed the lineAfter=network.target sound.target
toAfter=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.

edited

Edited 1 time

JoergZ2 edited Jan 6, 2017 (most recent)

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_confIPQoS 0x00
especially problems with the SSH access.
Problems with MPD were gone after I changed the lineAfter=network.target sound.target
toAfter=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.