jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23674
Joined: Sat Jul 30, 2011 7:41 pm

Re: Analogue audio testing

Fri Mar 04, 2016 3:28 pm

jdb wrote:
lb wrote:This is a very cool effort! Are there any ideas to get around the issues with PWM buffer underrun? Doesn't the VC4 have some internal memories that can be used, or maybe the builtin cache can help?
It's complicated. The code surrounding the SDRAM PVT/re-clocking is gnarly impenetrable VPU assembly and tying some sort of buffering into this is fraught with danger - if you get into a state where a VPU read makes it out of the cache and on to the bus to SDRAM with SDRAM disabled, the bus matrix stalls all the way down to the VPU which means your chip effectively locks up.

I need to stop DMA from stalling on a read while SDRAM is disabled which probably means peeking at the DMA read address, preloading 2-3 cachelines of the next set of data into GPU L2, then running PVT. Tricky to get right.
I remember adding some code to the GPU to turn of PVT whilst doing stuff that it interfered with, is that an option? (Nokia 808 42MP sensor data transfers had weird short bits of memory where data was missing). PVT simply didn't need to be run all the time. That may have changed with the 2837 though due to higher thermals transients.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Fri Mar 04, 2016 3:37 pm

I know that one of you guys disabled PVT automatically via rpi-update recently if the RAM clock was => 500MHz to help with RAM overclocking. I guess this still applies to the BCM2387 as someone has reported using the special schmoo sauce to get the RAM on his Pi3B up to 600MHz already. I don't know whether or not this has been pushed to normal updates or not though. Confirmation would be handy.
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2093
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Fri Mar 04, 2016 9:39 pm

It appears my bugfixes broke stuff. Alsa playback is inoperative with latest rpi-update firmware. Investigating...
Rockets are loud.
https://astro-pi.org

tvjon
Posts: 710
Joined: Mon Jan 07, 2013 9:11 am

Re: Analogue audio testing

Fri Mar 04, 2016 11:25 pm

jdb wrote:It appears my bugfixes broke stuff. Alsa playback is inoperative with latest rpi-update firmware. Investigating...
I have several audio devices connected to this Pi via bluetooth. I found it easier to get them all to work by installing pulseaudio.

I've occasionally had alsa "stick" before installing your new audio. However now it pauses regularly.

Tonight I wanted to use Fluidsynth, but as you can see each invocation failed with an audio i/o error.

Opening Pulseaudio's volume control, clicking on the mute icon, then click again, the blue slider lines appear.Now fluidsynth starts ok, & tapping the midi keyboard, sound works fine - for an hour or so, then silence again, & I then I need to reboot. Clicking on Pule's volume control only works once.

HTH
pulse.jpg
pulse.jpg (61.2 KiB) Viewed 5213 times

diegofromparis
Posts: 2
Joined: Sun Mar 06, 2016 11:49 am

Re: Analogue audio testing

Sun Mar 06, 2016 11:58 am

Hi,

I'm glad to see progress about poor jack sound output on RPI 2

I've done the sudo rpi-update and update my config.txt with preconized parameters.

That's work, sound are better (SNR is now very good). Maybe there is some small distort effect induced by the filter. But it's a big step.

I have just a big problem :
omxplayer play video correctly, but when i use omxplayer with this script :
https://raw.githubusercontent.com/magde ... layer-sync
the script continue to play the video indefinitely after the end and on screen the result is the movie freeze on the last frame (no loop).

That doesn't occur just with removing :

Code: Select all

disable_pvt=1
force_turbo=1
audio_pwm_mode=2
audio_sdm_mod_order=2 
in config.txt

This is a big issue for me. Anybody have an idea about what occurs in omxplayer-sync script ?

rosswesleyporter
Posts: 10
Joined: Tue Sep 22, 2015 3:53 am

Re: Analogue audio testing

Mon Mar 07, 2016 4:57 am

I tried this for the first time. Got no output from most players. But omxplayer worked. omxplayer doesn't use ALSA apparently. My son the musician declared it to be a substantial improvement in sound quality over the prior firmware.

BTW, on the first few tries rpi-update seemed to fill my /dev/root. So on the most recent try I used:

Code: Select all

sudo SKIP_BACKUP=1 rpi-update
I'm keen to test the next firmware update to see if I can get it to work in an ALSA-based setup. I published plans for a music player for people with dementia (http://dqmusicbox.com/), and it would be nice to drop the requirement for a USB audio adapter.

I do see some strange behavior in my current setup. The little music box above takes input from rotary encoders (dials) and takes appropriate action with VLC e.g. turning the volume dial calls VLC's audio_set_volume() method. That bit of code stops dead after just a few turns of the dial. Given the descriptions of others, I'm not trying to solve this problem now. I'll wait for the next firmware update. Mentioning this in case it is helpful to anyone.

Finally, my thanks to the person or people who are making this firmware update. I appreciate the work!

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2093
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Mon Mar 07, 2016 5:35 pm

Latest rpi-update firmware fixes a few bugs:

- Alsa should now work again - differences in how OMX/Alsa handle latencies should be handled properly...

- DMA could race against the VPU writing modulated samples to the playback buffer if the VPU ever got held off for long enough to miss a DMA interrupt (e.g. if the VPU is too busy). This is now reset every time the buffer wraps, so at most only ~5ms of audio will get corrupted on an underrun.

- I can still cause underruns when playing back software-decoded Youtube videos - cause still under investigation.
Rockets are loud.
https://astro-pi.org

unkzo
Posts: 49
Joined: Mon May 06, 2013 11:38 pm

Re: Analogue audio testing

Tue Mar 08, 2016 3:26 am

Congratulations for their efforts!

I measure some frequencys for a post in my blog about this and want to share here.
comparacao10khz.png
10Khz comparisson, old driver and new driver
comparacao10khz.png (29.48 KiB) Viewed 4892 times
rpi2_10khz_fft_old.png
10khz FFT old driver
rpi2_10khz_fft_old.png (31.93 KiB) Viewed 4892 times
rpi2_10khz_fft_new.png
10khz FFT experimental driver
rpi2_10khz_fft_new.png (30.87 KiB) Viewed 4892 times
Nice work jdb.

Reference: http://blog.everpi.net/2016/03/raspberr ... river.html

rosswesleyporter
Posts: 10
Joined: Tue Sep 22, 2015 3:53 am

Re: Analogue audio testing

Tue Mar 08, 2016 6:02 am

Monday's firmware update works with my ALSA-based setup! Sounds very very good. More specifically, Python-controlled VLC sounds very very good.

A quick note about headphones and volume from the built-in jack. I'm working with a hearing impaired population, so I'm a bit more concerned about volume than most. Sounds is sufficiently loud through my reference headphones -- $85 Sony MDR-7506 over the ear headphones. Also fine on $25 Sennheiser HD 202 II over the ear headphones. But not loud enough from $5 Panasonic RP-HT21 on ear headphones. However, those same low-end Panasonic headphones are sufficiently loud when driven from a $5 USB audio adapter on a Pi, and they sound surprisingly good. Jeff earlier suggested that I shouldn't count on driving big headphones from the built-in audio jack. I appreciate that heads up. Happily, there are some headphones that seem to work. Someone that knows more about headphones might be able to say why.

Next, I'm going to try this on an A+.

Thanks to jdb (and others?) for very good work on the firmware.

Sleep Mode zZ
Posts: 319
Joined: Sun Aug 19, 2012 5:56 am
Location: Finland

Re: Analogue audio testing

Tue Mar 08, 2016 8:03 am

rosswesleyporter wrote: A quick note about headphones and volume from the built-in jack. I'm working with a hearing impaired population, so I'm a bit more concerned about volume than most. Sounds is sufficiently loud through my reference headphones -- $85 Sony MDR-7506 over the ear headphones. Also fine on $25 Sennheiser HD 202 II over the ear headphones. But not loud enough from $5 Panasonic RP-HT21 on ear headphones. However, those same low-end Panasonic headphones are sufficiently loud when driven from a $5 USB audio adapter on a Pi, and they sound surprisingly good. Jeff earlier suggested that I shouldn't count on driving big headphones from the built-in audio jack. I appreciate that heads up. Happily, there are some headphones that seem to work. Someone that knows more about headphones might be able to say why.
Different headphones differ in sensitivity. Sensitivity tells how loud the phones get with a given electrical signal strength. Unfortunately there are two different units in use: dB/mW and db/V.

Panasonic tells that the sensitivity of the RP-HT21 is 100 dB/mW. The Sony MDR-7506 has a sensitivy of 104 dB/mW, so it can produce 4 dB more of sound pressure from a electrical signal of the same strength. Sennheiser HD 202 II reports a sensitivity of 115 dB and sites seem to assume that it is dB/mW. In that case it should be the loudest of those headphones.

On many other of their headphones Sennheiser reports their sensitivity in dB/V. If that 115 dB is dB/V, it could be converted to dB/mW, and the result would be 100.1 dB, according to this converter: http://www.jensign.com/S4/calc.html. (The converter calls db/mW "sensitivity" and db/V "efficiency" but I don't think that people usually make the distinction. I have read someone making the distinction but using the terms the other way around: db/V as "sensitivity" and db/mW as "efficiency".) In that case it should be very close to the Panasonics - that don't seem right according to what you reported, so maybe Sennheiser is really using dB/mW measurement to report the sensitivity of these headphones.

Impedance is another measurement of headphones. Many people seem to confuse impedance with sensitivity but it is not the same. It is related to sensitivity in that headphones with lower impedance are often louder than headphones with higher impedance - e.g. 32 ohm headphones are likely to be louder than 300 ohm headphone with the same input. But it is not necessarily so because impedance is only one factor among many to influence the sensitivity of headphones.

rosswesleyporter
Posts: 10
Joined: Tue Sep 22, 2015 3:53 am

Re: Analogue audio testing

Wed Mar 09, 2016 5:27 am

Sleep Mode zZ wrote: Different headphones differ in sensitivity. Sensitivity tells how loud the phones get with a given electrical signal strength. Unfortunately there are two different units in use: dB/mW and db/V.

Panasonic tells that the sensitivity of the RP-HT21 is 100 dB/mW. The Sony MDR-7506 has a sensitivy of 104 dB/mW, so it can produce 4 dB more of sound pressure from a electrical signal of the same strength. Sennheiser HD 202 II reports a sensitivity of 115 dB and sites seem to assume that it is dB/mW. In that case it should be the loudest of those headphones.
Sleep Mode zZ, that is a superb answer, thank you for taking the time. I feel lucky to be part of a community that is so knowledgeable and helpful.

java
Posts: 226
Joined: Mon Jul 21, 2014 9:41 am

Re: Analogue audio testing

Wed Mar 09, 2016 7:33 am

rosswesleyporter wrote:
Sleep Mode zZ wrote: Different headphones differ in sensitivity. Sensitivity tells how loud the phones get with a given electrical signal strength. Unfortunately there are two different units in use: dB/mW and db/V.

Panasonic tells that the sensitivity of the RP-HT21 is 100 dB/mW. The Sony MDR-7506 has a sensitivy of 104 dB/mW, so it can produce 4 dB more of sound pressure from a electrical signal of the same strength. Sennheiser HD 202 II reports a sensitivity of 115 dB and sites seem to assume that it is dB/mW. In that case it should be the loudest of those headphones.
Sleep Mode zZ, that is a superb answer, thank you for taking the time. I feel lucky to be part of a community that is so knowledgeable and helpful.
I must agree, one of the better answers to this question I have seen in years

Berde
Posts: 6
Joined: Tue Mar 08, 2016 9:58 pm

Re: Analogue audio testing

Thu Mar 10, 2016 4:35 pm

Is the code

disable_pvt=1
force_turbo=1
audio_pwm_mode=2
audio_sdm_mod_order=2

valid for OSMC users? Must Raspeberry Pi3 users install a new firmware too?

many thanks

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2093
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Thu Mar 10, 2016 4:36 pm

The settings must be present in config.txt. You need a start.elf with a build date after Feb 16th to have the driver available. Everything else should "Just Work".
Rockets are loud.
https://astro-pi.org

Berde
Posts: 6
Joined: Tue Mar 08, 2016 9:58 pm

Re: Analogue audio testing

Thu Mar 10, 2016 6:48 pm

Hi, I have a start_x.elf from 2th March and at the end of the /boot/config.txt I´ve inserted the code

disable_pvt=1
force_turbo=1
audio_pwm_mode=2
audio_sdm_mod_order=2

The noise at the main screens has decreased a lot but when I try to listen to music or watch a film the sound results very distorted / saturated (Raspberry Pi 3 with OSMC)

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2093
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Thu Mar 10, 2016 6:52 pm

I'd suggest getting the firmware build from the 7th of March which should fix that issue. In fact, if you wait a day or so there's another fix in the pipeline that will significantly reduce VPU usage for some workloads.
Rockets are loud.
https://astro-pi.org

Berde
Posts: 6
Joined: Tue Mar 08, 2016 9:58 pm

Re: Analogue audio testing

Thu Mar 10, 2016 8:49 pm

jdb wrote:I'd suggest getting the firmware build from the 7th of March which should fix that issue. In fact, if you wait a day or so there's another fix in the pipeline that will significantly reduce VPU usage for some workloads.


thank you very much, I did a
sudo apt-get update
sudo apt-get upgrade
but the start_x.elf is still from March 2nd. I will try again tomorrow with the new firmware

pik33
Posts: 182
Joined: Thu Sep 10, 2015 4:26 pm

Re: Analogue audio testing

Thu Mar 10, 2016 9:05 pm

Installed. It works. Tested with omxplayer, vlc and sunvox.

Loud sound is clipped! I played the Avatar with omxplayer and sound was in clipped in several louder places. This is typical in noise shaped driver, it gets saturated some bits before "hard limit". 16-bit samples have to be attenuated at input to avoid this. The amount of attenuation depends on noise shaping filter order. I will try to test it with 200Hz sine wave. The workaround at now is simply setting volume somewhat lower than 100%.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Thu Mar 10, 2016 9:13 pm

pik33 wrote:The workaround at now is simply setting volume somewhat lower than 100%.
Which volume?
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

pik33
Posts: 182
Joined: Thu Sep 10, 2015 4:26 pm

Re: Analogue audio testing

Thu Mar 10, 2016 9:23 pm

The main audio volume. Or the volume in the player. Wherever, where it makes the samples not to be in the full range.

If the sample value is for example 32760, the noise shaper tries to send something like 63-64-63-64... and 64 is out of range. Then you can hear distortions.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Analogue audio testing

Thu Mar 10, 2016 9:32 pm

pik33 wrote:The main audio volume. Or the volume in the player. Wherever, where it makes the samples not to be in the full range.

If the sample value is for example 32760, the noise shaper tries to send something like 63-64-63-64... and 64 is out of range. Then you can hear distortions.
Thanks. I was just checking as volume controls internal to applications always behaved very differently compared to the global master volume with regards to distortion with the old driver, or so it seemed. I was just wondering if this still applied, but seemingly not, or maybe I was just wrong in the first place. :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2093
Joined: Thu Jul 11, 2013 2:37 pm

Re: Analogue audio testing

Thu Mar 10, 2016 11:01 pm

pik33 wrote:Installed. It works. Tested with omxplayer, vlc and sunvox.

Loud sound is clipped! I played the Avatar with omxplayer and sound was in clipped in several louder places. This is typical in noise shaped driver, it gets saturated some bits before "hard limit". 16-bit samples have to be attenuated at input to avoid this. The amount of attenuation depends on noise shaping filter order. I will try to test it with 200Hz sine wave. The workaround at now is simply setting volume somewhat lower than 100%.
You are correct. The noise shaping results in computed output samples that have a considerably larger spread than simple truncation-based filtering. There's no easy way make this not suck - amplitude scaling is the recommended solution.

If you run your test case at say -3dB gain, is the issue still apparent?
Rockets are loud.
https://astro-pi.org

pik33
Posts: 182
Joined: Thu Sep 10, 2015 4:26 pm

Re: Analogue audio testing

Fri Mar 11, 2016 7:05 am

To avoid the clipping in my noise shaped driver I wrote for the Parallax Propeller microcontroller chip I attenuated input samples by 7/8 to avoid the clipping effect. The Propeller has no mul instruction, so I did it like this (propeller assembler but these instructions are common to all processors) :

Code: Select all


                        mov     temp, lsample
                        shl     temp,#1
                        add     lsample, temp
                        shl     temp,#1
                        add     lsample, temp
                        sar     lsample,#3


pik33
Posts: 182
Joined: Thu Sep 10, 2015 4:26 pm

Re: Analogue audio testing

Fri Mar 11, 2016 8:58 am

Which order is your noise shaper? The amplitude @ 200 Hz can be no more than about 0.6 to avoid distortions. (0.61 clear, 0.62 distorted). The simplest solution in this case is shift the sample 1 bit right.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5331
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Analogue audio testing

Fri Mar 11, 2016 12:16 pm

pik33 wrote:Which order is your noise shaper? The amplitude @ 200 Hz can be no more than about 0.6 to avoid distortions. (0.61 clear, 0.62 distorted). The simplest solution in this case is shift the sample 1 bit right.
One issue is the analogue level is currently a little on the quiet side for (many) headphones. This may have to be a bit of a compromise to rarely distort with real world content while still maintaining a usable volume level.

@jdb I assume the clipping signal is being saturated?

Return to “Advanced users”