[alsa-devel] Juli@ ICE1724 and 24 bit audio

[Demian Martin]

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.

Demian Martin
Product Design Services


-----Original Message-----
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
documentation
>> on that feature (bug). I had not seen that factoid anywhere.
>>
>> Demian Martin
>> PDS
>>
>>

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.