New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
hifiberry opened this Issue Aug 7, 2016 · 44 comments

Comments

Projects
None yet
@hifiberry

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Aug 7, 2016

Contributor

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.

Contributor

pelwell commented Aug 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Aug 7, 2016

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.

@clivem

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Aug 7, 2016

Contributor

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
Contributor

clivem commented Aug 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Aug 7, 2016

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

@clivem

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Aug 7, 2016

Contributor

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.

Contributor

clivem commented Aug 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Aug 7, 2016

No need to rush. Thanks for helping with this.

No need to rush. Thanks for helping with this.

@usul27

This comment has been minimized.

Show comment
Hide comment
@usul27

usul27 Aug 30, 2016

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?

usul27 commented Aug 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@juliusvaart

juliusvaart Aug 30, 2016

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?

@usul27

This comment has been minimized.

Show comment
Hide comment
@usul27

usul27 Aug 30, 2016

@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

usul27 commented Aug 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@juliusvaart

juliusvaart Aug 30, 2016

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

juliusvaart commented Aug 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Aug 30, 2016

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:

  • use the 2015-05 Raspbian lite and configure WLAN and DAC+Pro - WLAN is not working

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?

hifiberry commented Aug 30, 2016

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:

  • use the 2015-05 Raspbian lite and configure WLAN and DAC+Pro - WLAN is not working

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Sep 1, 2016

Contributor

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.

Contributor

pelwell commented Sep 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Sep 2, 2016

Contributor

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?

Contributor

pelwell commented Sep 2, 2016

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?

@open-homeautomation

This comment has been minimized.

Show comment
Hide comment
@open-homeautomation

open-homeautomation Sep 2, 2016

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)

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Sep 2, 2016

Contributor

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
Contributor

pelwell commented Sep 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@titopoquito

titopoquito Sep 6, 2016

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

titopoquito commented Sep 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@KozakIvan

KozakIvan Sep 20, 2016

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

KozakIvan commented Sep 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Sep 20, 2016

Contributor

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?

Contributor

pelwell commented Sep 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Sep 20, 2016

Collaborator

ITYM dmesg | grep brcmfmac

Collaborator

popcornmix commented Sep 20, 2016

ITYM dmesg | grep brcmfmac

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Sep 20, 2016

Contributor

Yes I did.

Contributor

pelwell commented Sep 20, 2016

Yes I did.

@Hyperjett

This comment has been minimized.

Show comment
Hide comment
@Hyperjett

Hyperjett Nov 13, 2016

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

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Nov 13, 2016

Contributor

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.

Contributor

pelwell commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Nov 13, 2016

Contributor

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.

Contributor

clivem commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Nov 13, 2016

Contributor

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

Contributor

pelwell commented Nov 13, 2016

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

@clivem

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Nov 13, 2016

Contributor

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

Contributor

clivem commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Nov 13, 2016

Contributor

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

Contributor

clivem commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Hyperjett

Hyperjett Nov 14, 2016

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

Hyperjett commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Nov 14, 2016

Contributor

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.

Contributor

pelwell commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Nov 16, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Nov 30, 2016

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?

@Hyperjett

This comment has been minimized.

Show comment
Hide comment
@Hyperjett

Hyperjett Nov 30, 2016

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.

@avian2

This comment has been minimized.

Show comment
Hide comment
@avian2

avian2 Dec 1, 2016

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.

avian2 commented Dec 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Dec 1, 2016

Contributor

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.

Contributor

pelwell commented Dec 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Dec 1, 2016

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

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

@Thijs-Rallye

This comment has been minimized.

Show comment
Hide comment
@Thijs-Rallye

Thijs-Rallye Dec 2, 2016

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)

@pelwell

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Dec 2, 2016

Contributor

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

Contributor

pelwell commented Dec 2, 2016

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

@Thijs-Rallye

This comment has been minimized.

Show comment
Hide comment
@Thijs-Rallye

Thijs-Rallye Dec 2, 2016

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

Thijs-Rallye commented Dec 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Dec 2, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@JoergZ2

JoergZ2 Jan 6, 2017

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.

JoergZ2 commented Jan 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Jan 6, 2017

Contributor

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

Contributor

pelwell commented Jan 6, 2017

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

@hifiberry

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Jan 6, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@hifiberry

hifiberry Jan 7, 2017

I think, we can close this bug.

I think, we can close this bug.

@Ruganer

This comment has been minimized.

Show comment
Hide comment
@Ruganer

Ruganer Nov 16, 2017

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

Ruganer commented Nov 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pelwell

pelwell Nov 16, 2017

Contributor

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

Contributor

pelwell commented Nov 16, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment