First round of audio tests done


I always thought 32bit samples are only used for proper alignment of 24bit samples on the PCI bus, discarding the extra 8bit. That's what my ICE1712-based sound card is doing, anyway, it doesn't even accept other sample formats.
 
Hmm, seems Pandora doesn't like 48000Hz sample frequency. When I play the original test file I can hear the interference when played on Pandora (easier to notice it with the frequency sweep). But if I resample the file down to 44100Hz then all the interference disappears. Can Pandora even play 48000Hz audio files directly (without extra processing happening on the background)? I used Audacious player for my test (ALSA output plugin).
 
Last edited by a moderator:
You're hearing Audacious (or alsa's) resampling artifacts, as it's resampling to 44.1kHz by default. You can check what's sent to hardware by running this command while audio plays:

cat /proc/asound/omap3pandora/pcm0p/sub0/hw_params

To send audio directly to DAC, use:

aplay -D hw:0,0 AudioTest.wav

This won't work with ED's file since the DAC can only accept stereo data. For that dmix can be used, which seems to keep the sample rate:

aplay -D plug:dmix AudioTest.wav

but I have no idea if it doesn't alter the audio some other way..

All this makes me wonder how ED did his tests..
 
Last edited by a moderator:
Yup, you are correct. When playing the test file with Audacious I get:

$ cat /proc/asound/omap3pandora/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 8192And can hear the artifacts.
But when I use "aplay -D plug:dmix AudioTest.wav" I get:

Code:
$ cat /proc/asound/omap3pandora/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
And zero artifacts.
 
I have some serious reservations regarding methodology used in these tests.
 
Most notably, the spectrum charts for Pandora look awfully lot like output of a moderately-shitty software resampler.
 

I simply used aplay on all devices to play the file and that worked fine.
 
Did you pass -D=hw to make sure you're sending the audio directly to the hardware, bypassing all software filtering in alsa?
 

aplay -D hw:0,0 AudioTest.wav
 
This won't work with ED's file since the DAC can only accept stereo data.
 
If that's so, I would suggest converting the file to stereo with SoX or whatever. This way we're sure nothing else is mangling the stream before it is sent to the hardware.
 

For that dmix can be used, which seems to keep the sample rate:
 
Actually, dmix is not capable of doing any format conversions. In fact, it sets a single format (sampling freq + sample format + channel count) in stone for all inputs and the output. Unless you configure it differently, the default parameters are: 48kHz, 16 bits signed, 2 channels.

If you want to send a different format than dmix is set for, you need to use the plug plugin, which converts between formats as needed...
 

aplay -D plug:dmix AudioTest.wav
but I have no idea if it doesn't alter the audio some other way..
...which is exactly what you are doing here. That line is creating a pipeline that sends audio first to the plug plugin for format conversion, and then to dmix. Note that this will convert everything to whatever format is set for dmix (probably the alsa default, if not set otherwise). Regardless of the input format.

If you want to just do minimal format conversion and not mixing (and not be restrained by the format set by the mixer), then the right line is:


aplay -D plug:hw file.wav
This will only do the conversions necessary to fit the supported HW formats, i.e.: if HW supports the sampling rate and channel count but not the sample format, only the sample format will be converted.
 
Well, the original file was Stereo, just converted it to Mono for the package as it uses less space then. So the Pandora played a stereo file.


If the 32bits are an issue though, I can redo the test on all systems with 16bit, no prob here.
 
I don't know what the dmix settings (if any) are set on those systems - the alsa defaults can be overridden by configuration files (either explicit ones, or one from the gnarly hairball under /usr/share/alsa) or AFAIRC by the hardware driver (if the normal defaults are unsupported by HW), so I would say the safest bet is just to use "aplay -D hw" to make sure all that is bypassed and no automatic conversions whatsoever are done.

"Bitness" changes are unlikely to produce problems, I would be more worried about unanticipated sample rate conversions.
 
I simply used aplay on all devices to play the file and that worked fine.
But it means you used alsa's resampling, which makes pandora's results look bad..
If you want to just do minimal format conversion and not mixing (and not be restrained by the format set by the mixer), then the right line is:

aplay -D plug:hw file.wavThis will only do the conversions necessary to fit the supported HW formats, i.e.: if HW supports the sampling rate and channel count but not the sample format, only the sample format will be converted.
That works, thanks for explanation.
Do you know how to use plug to send audio to different device, like "aplay -D hw:1,0" does but through plug, without messing with config files?
 
Last edited by a moderator:
Not exactly a lightdude but wouldn't it be nice to have a Pyra next to a DJ setup or mixer when on a gig with a band to control the lightshow and simultaniously record the show?
 
Last edited by a moderator:
I used opendmx already. Not a bad software.


But the killer feature for me would be to have everything built in not just as a usb addon with tons more of cables and boxes.


Will never happen anyway but one can dream :)
 
Apropos, do you know what a 5-pin XLR male connector could be on a microphone which can't sensibly be stereo? Just outputting the same thing twice on pins 2/3 and 4/5?

/derailing thread

Haven't been able to figure it out yet. Especially as I'm not even sure if the microphone is working.
 
Apropos, do you know what a 5-pin XLR male connector could be on a microphone which can't sensibly be stereo? Just outputting the same thing twice on pins 2/3 and 4/5?


/derailing thread


Haven't been able to figure it out yet. Especially as I'm not even sure if the microphone is working.
We have 5 pin DIN microphones here, they are mics with a push to talk button which make a gong go off before we can speak. We use it to ask artists backstage to come to the stage at the start of the show and such.

Sorry for the off-topicness ;)
 
Apropos, do you know what a 5-pin XLR male connector could be on a microphone which can't sensibly be stereo? Just outputting the same thing twice on pins 2/3 and 4/5?

/derailing thread

Haven't been able to figure it out yet. Especially as I'm not even sure if the microphone is working.
 We have 5 pin DIN microphones here, they are mics with a push to talk button which make a gong go off before we can speak. We use it to ask artists backstage to come to the stage at the start of the show and such.

Sorry for the off-topicness ;)
There is no push button on the mic. It's a "Superscope Cardiodid Condenser Microphone EC-3". Really old. Can't find any specs on the net.
Doesn't matter about the off topic, I'll blame it on the people who first mentioned XLR connectors. :)
 
Back
Top