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@xxxxxxxxx] Sent: Tuesday, February 10, 2009 7:35 AM To: Vedran Miletić Cc: Demian Martin; alsa-devel@xxxxxxxxxxxxxxxx Subject: Re: 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@xxxxxxxxx> 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
