You're not alone; I get that too. Odd.evilkitty wrote:Thanks, odd it gives 514 for me after a reboot
-
- Posts: 3
- Joined: Sun Feb 21, 2016 6:04 pm
Re: Analogue audio testing
Re: Analogue audio testing
Yes - me too I'm getting this 514 mode also, even after setting it to 2 in the config.txt - can anyone help? I'm running Retropie and wondering if anything there is altering the setting after the boot? I'd really like to hear the improvement I've read so much about!

Code: Select all
arm_freq=1000
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=500
disable_commandline_tags=2
disable_l2cache=1
display_rotate=1
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
hdmi_force_cec_address=65535
init_uart_clock=0x2dc6c00
lcd_framerate=60
over_voltage=2
over_voltage_avs=0x1b774
overscan_scale=1
pause_burst_frames=1
program_serial_random=1
sdram_freq=400
temp_limit=85
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 6040
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Analogue audio testing
Everyone does. @jdb uses the second byte for storing other internal state (it is called sdm_mode in the code)evilkitty wrote:Thanks, odd it gives 514 for me after a reboot
-
- Posts: 3
- Joined: Sun Feb 21, 2016 6:04 pm
Re: Analogue audio testing
Ahhhh ... thanks!dom wrote:Everyone does. @jdb uses the second byte for storing other internal state (it is called sdm_mode in the code)evilkitty wrote:Thanks, odd it gives 514 for me after a reboot
Re: Analogue audio testing

sorry to be a relatively clueless noob but I still don't get how to set this up - is it correct that even setting "...mode=2" then the RPi reports "...mode=514"?
I guess I'm asking as having updated the firmware and followed the instructions the sound is still clicking and popping more than I do after a full plate of beans!

Re: Analogue audio testing
Is there any news on the mixing contention/timeout issue mentioned a few posts back in june?
-
- Posts: 2
- Joined: Tue Nov 15, 2016 4:03 pm
Re: Analogue audio testing
Hi all,
I'm totally new here and saw this awesome post. tried the setting in config.txt :audio_pwm_mode=2. The sound quality is much much better. But I have a problem with bluetooth, after a couple of seconds (10 to 20) the music is just silent. I played around with amixer, sometimes when I change volume the sound comes back but goes silent after a while.
Anyone have a sollution for this?
I'm totally new here and saw this awesome post. tried the setting in config.txt :audio_pwm_mode=2. The sound quality is much much better. But I have a problem with bluetooth, after a couple of seconds (10 to 20) the music is just silent. I played around with amixer, sometimes when I change volume the sound comes back but goes silent after a while.
Anyone have a sollution for this?
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 6040
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: Analogue audio testing
Can you clarify that the audio issue only occurs with audio_pwm_mode=2? i.e. you remove that setting and the problem goes away?djpsycho82 wrote: I'm totally new here and saw this awesome post. tried the setting in config.txt :audio_pwm_mode=2. The sound quality is much much better. But I have a problem with bluetooth, after a couple of seconds (10 to 20) the music is just silent. I played around with amixer, sometimes when I change volume the sound comes back but goes silent after a while.
-
- Posts: 2
- Joined: Tue Nov 15, 2016 4:03 pm
Re: Analogue audio testing
Yes, tested that even more than once. I also use the Spotify service, Spotify also stops after a while with this setting. The sound quality is a really great difference though.
Re: Analogue audio testing
I must say thanks for adding this setting, even if it is experimental. I have managed to get excellent results with this on a Pi Zero with a filter circuit and dual 3W class D amplifier. 

Re: Analogue audio testing
Hi Zipplet,
After testing with a B+ I reused that device with a regular DAC.
However I still have a spare pi zero, and wanted to build a super minimal player from this.
Can you share the filter circuit you created to pull the analogue sound out of the GPIO and how you build that ?
If it is not to embarrassing, a photo of the build.
Regards M
After testing with a B+ I reused that device with a regular DAC.
However I still have a spare pi zero, and wanted to build a super minimal player from this.
Can you share the filter circuit you created to pull the analogue sound out of the GPIO and how you build that ?
If it is not to embarrassing, a photo of the build.
Regards M
zipplet wrote:I must say thanks for adding this setting, even if it is experimental. I have managed to get excellent results with this on a Pi Zero with a filter circuit and dual 3W class D amplifier.
Re: Analogue audio testing
djpsycho82 wrote:Hi all,
I'm totally new here and saw this awesome post. tried the setting in config.txt :audio_pwm_mode=2. The sound quality is much much better. But I have a problem with bluetooth, after a couple of seconds (10 to 20) the music is just silent. I played around with amixer, sometimes when I change volume the sound comes back but goes silent after a while.
Anyone have a sollution for this?
When you're "using bluetooth", can you post the full output of ps -aux?
What bluetooth peripherals are you using?
Rockets are loud.
https://astro-pi.org
https://astro-pi.org
Re: Analogue audio testing
Hi all,
I've just discover this parameter audio_pwm_mode and sound is incredibly better now.
However I have an issue while trying to play two musics simultaneously with omxplayer (I have a small homemade crossmix script to mix musics). So just before the first mp3 file finishes the second begins and the sound jerks.
Here is a sample:
http://mu6.me/135997
Of course it used to work smoothly without audio_pwm_mode.
If anyone knows something about that.. thank you in advance
I've just discover this parameter audio_pwm_mode and sound is incredibly better now.
However I have an issue while trying to play two musics simultaneously with omxplayer (I have a small homemade crossmix script to mix musics). So just before the first mp3 file finishes the second begins and the sound jerks.
Here is a sample:
http://mu6.me/135997
Of course it used to work smoothly without audio_pwm_mode.
If anyone knows something about that.. thank you in advance

Re: Analogue audio testing
That smells an awful lot like buffer underflow, i.e. we can't keep up with processing the sound samples.Aiexis wrote:Hi all,
I've just discover this parameter audio_pwm_mode and sound is incredibly better now.
However I have an issue while trying to play two musics simultaneously with omxplayer (I have a small homemade crossmix script to mix musics). So just before the first mp3 file finishes the second begins and the sound jerks.
Here is a sample:
http://mu6.me/135997
Of course it used to work smoothly without audio_pwm_mode.
If anyone knows something about that.. thank you in advance
It's a known issue that the new audio mode uses a lot of VPU processing power - I'd say that mixing two streams together is likely to fail as this requires two upsample operations (25% VPU time per operation) and one mix operation (unknown, but probably a significant percentage).
This is one of the reasons why the mode is not the default - high vector unit usage constrains other use-cases such as high-definition deinterlace video playback and stereo camera capture.
I've got a cunning plan to fix this, but currently my time on this is rather constrained. Watch this space.
Rockets are loud.
https://astro-pi.org
https://astro-pi.org
Re: Analogue audio testing
Thank you for your reply ! I'll keep an eye on this thread.
Re: Analogue audio testing
Please see this thread, where I post a video demo and instructions (with schematics). viewtopic.php?f=38&t=168084marcel-heijkoop wrote:Hi Zipplet,
After testing with a B+ I reused that device with a regular DAC.
However I still have a spare pi zero, and wanted to build a super minimal player from this.
Can you share the filter circuit you created to pull the analogue sound out of the GPIO and how you build that ?
If it is not to embarrassing, a photo of the build.
Regards M
zipplet wrote:I must say thanks for adding this setting, even if it is experimental. I have managed to get excellent results with this on a Pi Zero with a filter circuit and dual 3W class D amplifier.
-
- Posts: 12
- Joined: Tue Sep 22, 2015 3:53 am
Re: Analogue audio testing
Quick note to say that jdb's wonderful firmware update is a nice combination with vlc's volume boost and headphones. Earlier in this thread there was discussion that the Pi's built-in audio jack is a bit quiet for headphones. It's OK for me with high efficiency headphones, but not OK for those that are a bit hard of hearing. vlc's volume boost does a surprisingly good job of filling that gap. I normally limit vlc volume to 100%, but recently tried with 120%. I was impressed. I briefly tried 150% but that was too loud for my ears.
For those that want details, here is the context. I made a simple music player box for people with dementia, specifically for my Dad, and published the plans online https://dqmusicbox.com/. I just changed those plans from USB audio to instead use the Pi's built-in audio jack and vlc volume boost. Specifically vlc-nox controlled via Python bindings. It's working well. In about six hours of testing on an A+, I haven't experienced any firmware failures. I specifically used an A+, because I thought that would be the best stress test. I did get a few audio dropouts for a fraction of a second, perhaps once every two hours, but nothing of concern to me. My son the musician with young ears did a blind comparison of USB audio and Pi built-in audio. He judged the USB audio to be a bit better, but not by much. I *think* I can hear a bit of distortion above 100%, but Beethoven's 9th still sounds fantastic. I'm not suggesting that this is an audiophile solution, but I'm pretty happy.
For those that want details, here is the context. I made a simple music player box for people with dementia, specifically for my Dad, and published the plans online https://dqmusicbox.com/. I just changed those plans from USB audio to instead use the Pi's built-in audio jack and vlc volume boost. Specifically vlc-nox controlled via Python bindings. It's working well. In about six hours of testing on an A+, I haven't experienced any firmware failures. I specifically used an A+, because I thought that would be the best stress test. I did get a few audio dropouts for a fraction of a second, perhaps once every two hours, but nothing of concern to me. My son the musician with young ears did a blind comparison of USB audio and Pi built-in audio. He judged the USB audio to be a bit better, but not by much. I *think* I can hear a bit of distortion above 100%, but Beethoven's 9th still sounds fantastic. I'm not suggesting that this is an audiophile solution, but I'm pretty happy.
Re: Analogue audio testing
Yup, sigma-delta mode works really well with the correct setup - even on a pi zero as I demonstrated. I still maintain that it really is a line-out port and not a headphone out port. You might benefit from a very, very cheap headphone amplifier - a portable rechargeable battery powered one can be obtained quite cheaply online.rosswesleyporter wrote:Quick note to say that jdb's wonderful firmware update is a nice combination with vlc's volume boost and headphones.
Re: Analogue audio testing
Hi, thankyou for the very good new driver.
I've the little bug related to the SDRAM, but the solution is easy.
With this configuration in /boot/config.txt i hear a little "tic" when the governor changes the CPU and SDRAM speed:
The solution is to comment the SDRAM lines, avoiding its change in speed (the CPU speed change does not create audio problem).
I've the little bug related to the SDRAM, but the solution is easy.
With this configuration in /boot/config.txt i hear a little "tic" when the governor changes the CPU and SDRAM speed:
Code: Select all
arm_freq_min=350
arm_freq=1000
core_freq_min=200
core_freq=500
sdram_freq_min=250
sdram_freq=400
over_voltage=2
initial_turbo=30
gpu_mem=256
Code: Select all
arm_freq_min=350
arm_freq=1000
core_freq_min=200
core_freq=500
#sdram_freq_min=250
#sdram_freq=400
over_voltage=2
initial_turbo=30
gpu_mem=256
-
- Posts: 7
- Joined: Tue Oct 04, 2016 7:40 pm
Re: Analogue audio testing
I am a bit late but finally, I found this thread and tried the new driver on a Pi 1 Model B. And I have to say; Thank you so much for this incredible improvement!!
(Actually, I never understood why nobody ever implemented a sigma-delta driver while so many complained about the audio quality. Maybe, it's got something to do with the Hifiberrys and Iqaudios...)
Nevertheless, I have heavy distortions using squeezelite, independent of the volume (sox works great
). Has anybody managed to get it running well without distortions?
(Actually, I never understood why nobody ever implemented a sigma-delta driver while so many complained about the audio quality. Maybe, it's got something to do with the Hifiberrys and Iqaudios...)
Nevertheless, I have heavy distortions using squeezelite, independent of the volume (sox works great

-
- Posts: 7
- Joined: Tue Oct 04, 2016 7:40 pm
Re: Analogue audio testing
Tried it with a clean install and everything worked perfectlyfvzeppelin wrote:Nevertheless, I have heavy distortions using squeezelite, independent of the volume (sox works great). Has anybody managed to get it running well without distortions?

Thanks again to the developer!
Re: Analogue audio testing
Hi, this works great if you only have one sound source, so I suspect is uses ALSA and not Pulse?
If so what are the chances of supporting Pulse for mixed sounds?
You can see what I mean by trying these instructions + audio_pwm_mode=2:
viewtopic.php?p=1169979#p1169979
If so what are the chances of supporting Pulse for mixed sounds?
You can see what I mean by trying these instructions + audio_pwm_mode=2:
viewtopic.php?p=1169979#p1169979
https://github.com/tinspin/rupy - A tiny Java async HTTP application server.
Re: Analogue audio testing
No this is definitely a bug. You can run two instances of speaker-test without the advanced audio but with it enabled one of the instances will always block. The advanced audio driver should have the same behaviour as the default one.bullen wrote:Hi, this works great if you only have one sound source, so I suspect is uses ALSA and not Pulse?
If so what are the chances of supporting Pulse for mixed sounds?
You can see what I mean by trying these instructions + audio_pwm_mode=2:
viewtopic.php?p=1169979#p1169979
Rockets are loud.
https://astro-pi.org
https://astro-pi.org
Re: Analogue audio testing
Ok, so what would be the course of action to get this to work?
Talk to the author?
Talk to the author?
https://github.com/tinspin/rupy - A tiny Java async HTTP application server.
Re: Analogue audio testing
Given that the author is myself, pester me more?
It's on my to-do list. I also have to reduce the VPU usage % by a factor of 4 or more before this mode is ready for primetime.

It's on my to-do list. I also have to reduce the VPU usage % by a factor of 4 or more before this mode is ready for primetime.
Rockets are loud.
https://astro-pi.org
https://astro-pi.org