[alsa-devel] Juli@ ICE1724 and 24 bit audio
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
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.
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.
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
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ć
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ć 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.
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.
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.
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.
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.
participants (3)
-
Demian Martin -
Pavel Hofman -
Vedran Miletić