[alsa-devel] Juli@ ICE1724 and 24 bit audio
demianm_1 at yahoo.com
Tue Feb 10 17:21:16 CET 2009
Now I'm more confused. I'll try the experiments today and report on what I
find. If plughw with aplay works and xine doesn't that will explain a lot.
I should have some good experimental answers in a few hours.
Product Design Services
From: Pavel Hofman [mailto:pavel.hofman at insite.cz]
Sent: Tuesday, February 10, 2009 7:35 AM
To: Vedran Miletić
Cc: Demian Martin; alsa-devel at alsa-project.org
Subject: Re: [alsa-devel] Juli@ ICE1724 and 24 bit audio
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 at yahoo.com> wrote:
>> Thanks, I'll try that. I guess this e-mail will serve as more
>> on that feature (bug). I had not seen that factoid anywhere.
>> Demian Martin
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
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.
More information about the Alsa-devel