Juli@ ICE1724 and 24 bit audio

Juli@ ICE1724 and 24 bit audio

[Demian Martin]

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?

 

Demian Martin

Product Design Services

784 Cary Drive

San Leandro, CA 94577

209 613 6990

Re: Juli@ ICE1724 and 24 bit audio

[Pavel Hofman]

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.

Re: Juli@ ICE1724 and 24 bit audio

[Demian Martin]

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.

Re: Juli@ ICE1724 and 24 bit audio

[Vedran Miletić]

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ć
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Juli@ ICE1724 and 24 bit audio

[Demian Martin]

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ć

Re: Juli@ ICE1724 and 24 bit audio

[Vedran Miletić]

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ć
>
>


-- 
Vedran Miletić
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Juli@ ICE1724 and 24 bit audio

[Pavel Hofman]

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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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@insite.cz] 
Sent: Tuesday, February 10, 2009 7:35 AM
To: Vedran Miletić
Cc: Demian Martin; alsa-devel@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@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.

Re: Juli@ ICE1724 and 24 bit audio

[Demian Martin]

Testing updates. 
First aplay w/ hw:0,0 gets this useless result:
linuxmce@dcerouter:/home/public/data/audio/RR HDaudio$ aplay -v -Dhw:0,0
1_Mystery_Pacific.wav                                      
Playing WAVE '01_Mystery_Pacific.wav' : Signed 24 bit Little Endian in
3bytes, Rate 176400 Hz, Stereo
aplay: set_params:900: Sample format non available

Then w/ plughw:0,0
linuxmce@dcerouter:/home/public/data/audio/RR HDaudio$ aplay -v -Dplughw:0,0
01_Mystery_Pacific.wav
Playing WAVE '01_Mystery_Pacific.wav' : Signed 24 bit Little Endian in
3bytes, Rate 176400 Hz, Stereo
Plug PCM: Linear conversion PCM (S32_LE)
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S24_3LE
  subformat    : STD
  channels     : 2
  rate         : 176400
  exact rate   : 176400 (176400/1)
  msbits       : 24
  buffer_size  : 32768
  period_size  : 8192
  period_time  : 46439
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 8192
  xfer_align   : 8192
  start_threshold  : 32768
  stop_threshold   : 32768
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave: Hardware PCM card 0 'ESI Juli@' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 2
  rate         : 176400
  exact rate   : 176400 (176400/1)
  msbits       : 24
  buffer_size  : 32768
  period_size  : 8192
  period_time  : 46439
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 8192
  xfer_align   : 8192
  start_threshold  : 32768
  stop_threshold   : 32768
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
underrun!!! (at least 97.039 ms long)
Status:
  state       : XRUN
  trigger_time: 1234296814.359013515
  tstamp      : 1234296814.456029856
  delay       : 0
  avail       : 32768
  avail_max   : 32768
Aborted by signal Interrupt...

I have underrun issues I need to look into as well. Perhaps some buffer
setting needs to be changed? This is on a Via platform so it doesn't have a
whole lot of power. Any suggestions would be appreciated. That is an area
where I have gotten very lost in the past.


Demian Martin
Product Design Services
784 Cary Drive
San Leandro, CA 94577
209 613 6990


-----Original Message-----
From: Pavel Hofman [mailto:pavel.hofman@insite.cz] 
Sent: Tuesday, February 10, 2009 7:35 AM
To: Vedran Miletić
Cc: Demian Martin; alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Juli@ ICE1724 and 24 bit audio

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.

Re: Juli@ ICE1724 and 24 bit audio

[Demian Martin]

I confirmed that aplay and plughw:0,1 work fine. Aplay and hw:0,1 don't work
at all.

And that Xine is the culprit. Now to find out how to fix/work around Xine.

Demian Martin
Product Design Services


-----Original Message-----
From: Pavel Hofman [mailto:pavel.hofman@insite.cz] 
Sent: Tuesday, February 10, 2009 7:35 AM
To: Vedran Miletić
Cc: Demian Martin; alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Juli@ ICE1724 and 24 bit audio



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.

Re: Juli@ ICE1724 and 24 bit audio

[Pavel Hofman]

Pavel Hofman napsal(a):
> Demian Martin napsal(a):
>> I confirmed that aplay and plughw:0,1 work fine. Aplay and hw:0,1 
>> don't work
>> at all.
>>
>> And that Xine is the culprit. Now to find out how to fix/work around 
>> Xine.
>>
>> Demian Martin
>> Product Design Services
>>
>>
> 
> The older aplay you most likely use does not support 24bit properly. 
> Install the latest alsa-utils from git and you will be fine.
> 

Sorry for confusion. Your aplay handles already 24bit correctly. ICE1724
supports only 32bit natively (as most modern cards do), and hw:0
correctly does not accept any other format. That is why plughw converts
your 24-bit format to 32bit - see the verbose output.

For testing purposes make a 32bit file (sox -V in.wav -4 32.wav), and
aplay -v -Dhw:0 32.wav will play fine.

Pavel


-- 
-----------------

inSITE, s.r.o.

Rubesova 29, 326 00 Plzen
Tel. +420 377 449 358
Fax  +420 222 745 553
GSM: +420 603 163 973
Email: pavel.hofman@insite.cz

www.educity.cz, www.jobcity.cz
www.meetings.cz, www.hrzive.cz
www.comben.cz, www.insite.cz

-------------------------------
Navstivte www.educity.cz, server
s nejvetsi nabidkou profesniho
vzdelavani na ceskem internetu.

Re: Juli@ ICE1724 and 24 bit audio

[Pavel Hofman]

Demian Martin napsal(a):
> I confirmed that aplay and plughw:0,1 work fine. Aplay and hw:0,1 don't work
> at all.
> 
> And that Xine is the culprit. Now to find out how to fix/work around Xine.
> 
> Demian Martin
> Product Design Services
> 
> 

The older aplay you most likely use does not support 24bit properly.
Install the latest alsa-utils from git and you will be fine.

Perhaps the Xine problem is caused by the passthrough mode. E.g. in
mplayer the hwac3/hwdts output decoders for passthrough run in 16bit
only, but they work actively with the non-audio format. You can check
xine/xinelib code, the alsa output should not be that difficult to analyze.

Regards,

Pavel.