Vedran Miletić wrote:
Yeah, ALSA's documentation is actually quite lacking on many fronts and is mostly scattered around various wikis and mailing lists.
But I guess it is as it is, complaining about it won't fix it.
On 2/9/09, Demian Martin demianm_1@yahoo.com wrote:
Thanks, I'll try that. I guess this e-mail will serve as more documentation on that feature (bug). I had not seen that factoid anywhere.
Demian Martin PDS
-----Original Message----- From: Vedran Miletić [mailto:rivanvx@gmail.com] Sent: Monday, February 09, 2009 1:39 PM To: Demian Martin Cc: Pavel Hofman; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Juli@ ICE1724 and 24 bit audio
The plughw part is what makese it resample to 16-bit. You should just use hw.
On Mon, Feb 9, 2009 at 10:29 PM, Demian Martin demianm_1@yahoo.com wrote:
Pavel: Thanks for all your help and work on this project.
I'm using the Juli@ card because it supports 176.4KHz. The only other candidates are much more expensive and bring their own problems.
I'm using Xine set for dolby/dts passthrough which seems to send the
audio
data at its native rate. The resampling is bypassed (Dolby Digital would
be
trashed otherwise).
I will try playing the files from the command line when I am next in
front
of the system, tomorrow.
This is the Asound.conf: Asound.conf (/etc)
pcm.asym_spdif {
type asym playback.pcm "plughw:0,1" capture.pcm "plughw:0"}
pcm.!default asym_spdif
Demian Martin PDS
-----Original Message----- From: Pavel Hofman [mailto:pavel.hofman@insite.cz] Sent: Monday, February 09, 2009 12:27 PM To: Demian Martin Cc: alsa-devel@alsa-project.org; pavel.hofman@insite.cz Subject: Re: [alsa-devel] Juli@ ICE1724 and 24 bit audio
Demian Martin napsal(a):
I have the driver working fine for sample rates from 44.1K to 196K
however
it seems to be truncating the data to 16 bits. I wasn't sure until I
started
testing with the HRx 176.4K 24 bit files that have an embedded HDCD
flag
in
the LSB. The files work OK on Windoze systems (with a lot of low
level
settings tweaked) and they play fine but the flag isn't detected by a
system
that can detect them. Further looking at the data stream with a scope
it
seems the last 8 bits aren't changing. Is there anything I can do to
control
the driver to confirm this problem or change the playback settings to
make
it work?
How do you play the files? Do you use the hw or plug:hw device? IIRC, the standard-setup dmix resampler is 16-bit only.
I did tests with SPDIF OUT/IN and found it bit-perfect, for 24bit too.
Regular ICE1724 cards do not output 176.4kHz SPDIF, only 88.2kHz. But Juli is not affected by that bug.
Regards,
Pavel.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Vedran Miletić
What makes you guys think the plug plugin trims the data down to 16bits? Sure if the rate is changed (the source code suggests only the low-quality linear rate algorithm supports above-16bit format - operation convert, the other resampling algorithms convert using the operation convert_s16).
Ice1724 supports all the general rates natively, the rate conversion in the plug plugin should not kick in for common audio formats. The only case I can think of would be switching Juli to external SPDIF-IN clock - the hw.rate_min = hw.rate_max = actual_rate and the automatic rate conversion could happen.
I did not use the hw device in my tests since all the tested tracks would have to be 32-bit for the hw device to accept the format when played via my favorite aplay.
My 2 cents guess is xine does the conversion.
Regards,
Pavel.