Re: plughw versus hw

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pierre Habraken!

 On 2011.06.21 at 13:55:12 +0200, Pierre Habraken wrote next:

> Hello Vladimir,
> 
> Thank you for your reply.
> 
> I just bought an Asus Xonar DX sound card, for sending 24bits/96KHz
> stereo flac files to an external DAC.
> I am using Alsa 1.0.21 on a PC running Ubuntu 10.04 with Linux
> kernel 2.6.32-32.
> Running aplay, I can't use hw for reading 24/96 files:
> 
> $ aplay -D hw:0,1 Prelude.wav
> Playing WAVE 'Prelude.wav' : Signed 24 bit Little Endian in 3bytes,
> Rate 96000 Hz, Stereo
> aplay: set_params:990: Sample format non available
> Available formats:
> - S16_LE
> - S32_LE
> $

Obviously, your card doesn't support 24 bit but supports 32-bit S32_LE
instead.

> Adding the switch -f S32_LE does not help:
> 
> $ aplay -D hw:0,1 -f S32_LE Prelude.wav
> Warning: format is changed to S24_3LE
> Playing WAVE 'Prelude.wav' : Signed 24 bit Little Endian in 3bytes,
> Rate 96000 Hz, Stereo
> aplay: set_params:990: Sample format non available
> Available formats:
> - S16_LE
> - S32_LE
> $

Yes. Wrong format. You have to send *real* 32-bit stream to playback,
S32_LE. This is rather inconvenient and it's a reason why you shouldn't
use hw device.

What aplay did here isn't 24 bit to 32 bit conversion; it simply changed
form of 24 bit samples to "S24_3LE". S24_3LE is 32-bit format for 24-bit
samples, with 8 bit of padding. So it's very easy to convert between
S24_3LE and S24_LE, you just add or remove padding - which aplay did for
you here. While S24_3LE samples are 32-bit, they aren't what your card
likes, it needs true S32_LE.

Try converting stream to 32-bit before feeding it to aplay:
sox Prelude.wav -b 32 output.wav

this should generate true S32_LE stream, try playing it.


> If I use plughw instead of hw, it works fine:
> 
> $ aplay -D plughw:0,1 Prelude.wav
> Playing WAVE 'Prelude.wav' : Signed 24 bit Little Endian in 3bytes,
> Rate 96000 Hz, Stereo
> ^CAborted by signal Interrupt...
> $
> 
> Does it mean that the 24bits stream has to be converted to 16bits
> before being sent to the device and then to the DAC ?

It could mean that, or (more likely) that it's converting it to 32-bit
S32_LE and then sends (probably downconverting to 24-bit in process..)
it to DAC.

Easy to check, do something like
$ cat /proc/asound/card0/pcm1p/sub0/hw_params 

during playback. Here card 0 is first audio card and pcm1p is second
playback stream - numbers can be different from you. For example, I get

access: MMAP_INTERLEAVED
format: S24_3BE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 960
buffer_size: 7680

which means that playback works in S24_3BE (another strange format,
32-bit format with padded 24-bit samples, big endian). Obviously my
stream wasn't like that, and no sane program would've used that for
output; therefore plughw device is only that works.


If you want to ensure that higher sample rate and format are used, you
can write manual conversion in .asoundrc. Instead of using hw or plughw,
you should use "default" device, and you can add conversion to S32_LE to
that default device section - and redirect to plughw after conversion.
Or you can add both S32_LE and sample rate conversion and redirect to hw
device even. Unfortunately, I can't provide you help with writing
asoundrc.


Now, easier way is to use some sound server, like jack (for professional
apps) or pulseaudio (for normal desktop). I use later, and have settings
to ensure that it converts all streams to 96khz S24_3BE, so DAC accepts
maximum quality streams all the time. I don't have to worry about what
applications send at all, because pulse ensures that audio device is
used only in this mode.



-- 

Vladimir

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user


[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux