-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
[ALSA] wrong volume when starting playback #570
Comments
Same issue here, with my Raspberry Pi model B, and a fresh new Raspbian ;). |
@computer007 This is a fixed 256M/256M arm/gpu memory split test build. Replace your current start.elf file with it. |
Now in latest rpi-update firmware. Please test. |
kernel: config: Add CONFIG_NFS_SWAP See: #266 firmware: alsa: fix for wrong volume when starting playback See: raspberrypi/linux#570 firmware: Support passthrough through alsa with channels=0 See: raspberrypi/linux#528
kernel: config: Add CONFIG_NFS_SWAP See: raspberrypi/firmware#266 firmware: alsa: fix for wrong volume when starting playback See: raspberrypi/linux#570 firmware: Support passthrough through alsa with channels=0 See: raspberrypi/linux#528
@popcornmix Thank you. I just tried it, and it seems to have solved the bug. I will confirm it after further tests by the end of the week :) PS: By curiosity, what caused the bug. I had a look at this file https://github.com/raspberrypi/linux/blob/rpi-patches/sound/arm/bcm2835.c, but I did not notice something special. |
The fix was done on the firmware side. |
Hello, |
- Add a work-around for audio issues in older Raspberry firmware. raspberrypi/linux#570 - Move a few things around to give DHCP a little more time to come up before we log/announce the IP addresses. This way we're doing something rather than just waiting in WaitForDHCPIPs for the IP(s) to come up. - Disable wifi interface by default on stock SD image so that WaitForDHCPIPs doesn't wait 60 seconds for it to get an IP address. When users configure wifi via the Network Config screen, we'll detect that and wait for an IP to come up on the wireless interface. - Execute flite in the background so that we can proceed with bootup while it announces our IP addresses. Shaves another few seconds off our boot time.
kernel: config: Add CONFIG_NFS_SWAP See: raspberrypi#266 firmware: alsa: fix for wrong volume when starting playback See: raspberrypi/linux#570 firmware: Support passthrough through alsa with channels=0 See: raspberrypi/linux#528
do_xdp_generic must be called inside rcu critical section with preempt disabled to ensure BPF programs are valid and per-cpu variables used for redirect operations are consistent. This patch ensures this is true and fixes the splat below. The netif_receive_skb_internal() code path is now broken into two rcu critical sections. I decided it was better to limit the preempt_enable/disable block to just the xdp static key portion and the fallout is more rcu_read_lock/unlock calls. Seems like the best option to me. [ 607.596901] ============================= [ 607.596906] WARNING: suspicious RCU usage [ 607.596912] 4.13.0-rc4+ raspberrypi#570 Not tainted [ 607.596917] ----------------------------- [ 607.596923] net/core/dev.c:3948 suspicious rcu_dereference_check() usage! [ 607.596927] [ 607.596927] other info that might help us debug this: [ 607.596927] [ 607.596933] [ 607.596933] rcu_scheduler_active = 2, debug_locks = 1 [ 607.596938] 2 locks held by pool/14624: [ 607.596943] #0: (rcu_read_lock_bh){......}, at: [<ffffffff95445ffd>] ip_finish_output2+0x14d/0x890 [ 607.596973] #1: (rcu_read_lock_bh){......}, at: [<ffffffff953c8e3a>] __dev_queue_xmit+0x14a/0xfd0 [ 607.597000] [ 607.597000] stack backtrace: [ 607.597006] CPU: 5 PID: 14624 Comm: pool Not tainted 4.13.0-rc4+ raspberrypi#570 [ 607.597011] Hardware name: Dell Inc. Precision Tower 5810/0HHV7N, BIOS A17 03/01/2017 [ 607.597016] Call Trace: [ 607.597027] dump_stack+0x67/0x92 [ 607.597040] lockdep_rcu_suspicious+0xdd/0x110 [ 607.597054] do_xdp_generic+0x313/0xa50 [ 607.597068] ? time_hardirqs_on+0x5b/0x150 [ 607.597076] ? mark_held_locks+0x6b/0xc0 [ 607.597088] ? netdev_pick_tx+0x150/0x150 [ 607.597117] netif_rx_internal+0x205/0x3f0 [ 607.597127] ? do_xdp_generic+0xa50/0xa50 [ 607.597144] ? lock_downgrade+0x2b0/0x2b0 [ 607.597158] ? __lock_is_held+0x93/0x100 [ 607.597187] netif_rx+0x119/0x190 [ 607.597202] loopback_xmit+0xfd/0x1b0 [ 607.597214] dev_hard_start_xmit+0x127/0x4e0 Fixes: d445516 ("net: xdp: support xdp generic on virtual devices") Fixes: b5cdae3 ("net: Generic XDP") Acked-by: Daniel Borkmann <[email protected]> Signed-off-by: John Fastabend <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
…rage We no longer need the workaround for the volume adjustment at boot. The firmware issue was fixed a long time ago as referenced in raspberrypi/linux#570 When using a NFS share for /home/fpp/media, the storage source location was not getting parsed properly due to the length of the field, so change the parsing of the findmnt output a little to handle this case.
When I set the global system volume with alsa-lib before running VLC or mpg123, the level is properly modified when looking at alsamixer, but the playback starts with a very high volume, ignoring the one configured with alsa-lib. Once playback has started, calling again alsa-lib to set the volume properly modifies the volume and the displayed volume level (alsamixer).
OS: raspbian
Kernel 3.10.36+ #665 PREEMPT
firmware updated with "rpi-update"
pulse-audio not installled, only ALSA
Result of "modinfo" command:
To reproduce the bug with raspbian:
Here is what I experience:
Here is the code "test-alsa-vlc.c":
And the "makefile":
In the case where it works when launching for the first time, try rebooting, and the bug should occur.
If you need more info, just ask!
Thank you
The text was updated successfully, but these errors were encountered: