SPDIF/IEC958 sample rate on HDA/ALC882

SPDIF/IEC958 sample rate on HDA/ALC882

[Erik Slagter]

Sorry if this is considered to be "user" question, but I got no response
at all from the "user" list. Guess the real cracks hang around here.

I have lots of questions I cannot resolve from all of the docs, but for
the moment I'll stick to the most important one.

The combination of HDA/ALC882 should be able to deliver sound at 96 kHz
(hda..., right...) Also the ALC882 datasheet says it can deliver sound
at 96 kHz.

In practise, though, I cannot get it to output any other sample rate
than 48 kHz. Any other sample rate handed to hw:0,0 is simply converted
(somewhere??? and badly...) to 48 kHz and the SPDIF is still driven at
48 kHz.

iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is
still at 48 kHz. Some other flags from iecset are actually honoured
(like "data" and "emphasis").

I can ask aplay to play at various rates (from a suitable PCM file), but
it complains at any other rate than 44.1 or 48 (notably 32) kHz that the
rate is not supported. It plays at 44.1 kHz though. And again converts
it to 48 kHz! Sigh...

Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
I cannot make work properly at all (only one channel is output, large
chunks are discarded, much much clipping).

Please help, I am totally lost here...

Info:

  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 18: [ 0- 2]: digital audio playback
 24: [ 0- 0]: digital audio capture
 25: [ 0- 1]: digital audio capture
 33:        : timer

Alsa version 1.0.12rc1 (linux 2.6.18) on X86_64

Other output on request.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Takashi Iwai]

Hi,

Sorry, looks like I overlooked this post...

At Wed, 01 Nov 2006 17:58:55 +0100,
Erik Slagter wrote:
> 
> Sorry if this is considered to be "user" question, but I got no response
> at all from the "user" list. Guess the real cracks hang around here.
> 
> I have lots of questions I cannot resolve from all of the docs, but for
> the moment I'll stick to the most important one.
> 
> The combination of HDA/ALC882 should be able to deliver sound at 96 kHz
> (hda..., right...) Also the ALC882 datasheet says it can deliver sound
> at 96 kHz.
> 
> In practise, though, I cannot get it to output any other sample rate
> than 48 kHz. Any other sample rate handed to hw:0,0 is simply converted
> (somewhere??? and badly...) to 48 kHz and the SPDIF is still driven at
> 48 kHz.
> 
> iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is
> still at 48 kHz. Some other flags from iecset are actually honoured
> (like "data" and "emphasis").

It's simply because iecset program doesn't support the rates over
48kHz.  But the hda-intel driver supports the rate, AFAIK.
(At least, there is no particular code that restricts over-48kHz.)

One thing to be noted is that if you use "hw" PCM device, you have to
set up the SPDIF status bits _manually_ via control API.  If you use
"iec958" or "spdif" PCM device, you can pass these bits as optional
arguments at opening the PCM.

> I can ask aplay to play at various rates (from a suitable PCM file), but
> it complains at any other rate than 44.1 or 48 (notably 32) kHz that the
> rate is not supported. It plays at 44.1 kHz though. And again converts
> it to 48 kHz! Sigh...

Who complains?  At least, the driver won't.

> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
> I cannot make work properly at all (only one channel is output, large
> chunks are discarded, much much clipping).

The first PCM device is for the multi-output PCM.  It's for both
analog and digital.  The dedicated SPDIF is the secondary one.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Takashi Iwai]

At Tue, 28 Nov 2006 14:13:25 +0100,
Erik Slagter wrote:
> 
> Takashi Iwai wrote:
> >> iecset allows me to set the rate to 32/44.1/48 kHz, the spdif output is
> >> still at 48 kHz. Some other flags from iecset are actually honoured
> >> (like "data" and "emphasis").
> 
> > It's simply because iecset program doesn't support the rates over
> > 48kHz.  But the hda-intel driver supports the rate, AFAIK.
> > (At least, there is no particular code that restricts over-48kHz.)
> 
> The problem is that whatever I set the sampling rate to, the output is
> ALWAYS 48 Khz, either set to 32, 41 or 48 Khz. I am not even talking
> about the higher rates.
> 
> > One thing to be noted is that if you use "hw" PCM device, you have to
> > set up the SPDIF status bits _manually_ via control API.  If you use
> > "iec958" or "spdif" PCM device, you can pass these bits as optional
> > arguments at opening the PCM.
> 
> I've tried that, but it's ehhhrrrmmm lacking some documentation.

You have all the source code, what else? :)

> >> I can ask aplay to play at various rates (from a suitable PCM file), but
> >> it complains at any other rate than 44.1 or 48 (notably 32) kHz that the
> >> rate is not supported. It plays at 44.1 kHz though. And again converts
> >> it to 48 kHz! Sigh...
> 
> > Who complains?  At least, the driver won't.
> 
> aplay complains, I suspect as a result of a return value from the
> driver. I can give you the output if it helps. I can even do an strace.

strace doesn't help much, I guess.  Provide rather what exactly you
did and what exactly you got, at first.  I can't reproduce nor check
anything unless I get precise information.  Also, try always the
latest version if you want to debug/analyzie something, i.e. ALSA HG
version.

> >> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
> >> I cannot make work properly at all (only one channel is output, large
> >> chunks are discarded, much much clipping).
> 
> > The first PCM device is for the multi-output PCM.  It's for both
> > analog and digital.  The dedicated SPDIF is the secondary one.
> 
> But why does the second interface gives _some_ (although wrong) output
> on my spdif output then?

No idea, possibly wrong parameters are passed.

> Anyway, I double checked and the alc882 CAN output at various rates,
> also on the sp/dif output.

It's likely true.  Better to check the proc file content of codec#*
file rather than reading datasheets (what are often wrong), though.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Takashi Iwai]

Hi,

[Don't forget add alsa-devel to Cc]

At Tue, 28 Nov 2006 19:42:30 +0100,
Erik Slagter wrote:
> 
> >>>> I can ask aplay to play at various rates (from a suitable PCM file), but
> >>>> it complains at any other rate than 44.1 or 48 (notably 32) kHz that the
> >>>> rate is not supported. It plays at 44.1 kHz though. And again converts
> >>>> it to 48 kHz! Sigh...
> >>> Who complains?  At least, the driver won't.
> >> aplay complains, I suspect as a result of a return value from the
> >> driver. I can give you the output if it helps. I can even do an strace.
> 
> > strace doesn't help much, I guess.  Provide rather what exactly you
> > did and what exactly you got, at first.  I can't reproduce nor check
> > anything unless I get precise information.  Also, try always the
> > latest version if you want to debug/analyzie something, i.e. ALSA HG
> > version.
> 
> HG???

Mercurial.  See the download page.

> I can give you output of the FC5 versions, i.e. 1.0.11

That's way too old version.

> Anyway, I'm only using aplay and iecset from it.
> 
> The kernel is 2.6.18, I did try 2.6.19-rc4, but it has too many
> problems, and for alsa functionality it doesn't appear to matter anyway.
> 
> If you happen to have a few lines of C code that does no more than
> setting the output digital device to sample rate x, I'd be obliged.
> 
> Also I really don't get the relationship between the sample rate of the
> wav file I'm using for testing (with aplay) and iecset. I'd expect that
> aplay would set the sample (locking) rate of the spdif interface to the
> sample frequency as the wav file, what is the use of iecset (rate) then?
> I am using hw:0,0 to really avoid software resampling.

Well, still I didn't write what you did and what you got...

> >>>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
> >>>> I cannot make work properly at all (only one channel is output, large
> >>>> chunks are discarded, much much clipping).
> >>> The first PCM device is for the multi-output PCM.  It's for both
> >>> analog and digital.  The dedicated SPDIF is the secondary one.
> >> But why does the second interface gives _some_ (although wrong) output
> >> on my spdif output then?
> 
> > No idea, possibly wrong parameters are passed.
> 
> By whom or what? Actually I don't care that much, but it looks like a
> bug to me.

Possibly.  But too little information to analyze.

> >> Anyway, I double checked and the alc882 CAN output at various rates,
> >> also on the sp/dif output.
> 
> > It's likely true.  Better to check the proc file content of codec#*
> > file rather than reading datasheets (what are often wrong), though.
> 
> I did try to parse this file, but I could not make anything useful out
> of it. I attached it for your convenience.
> 
> I also tried to decipher the "rates" values from the constants in the
> source code, but it's really not doable (include include define include
> etc.)

Try HG version, and you'll see what they mean better.

Anyway, I'll be in vacation for a couple of weeks from tomorrow, so
the debugging is likely pending...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 1882 bytes --]

Takashi Iwai wrote:

>> Also I really don't get the relationship between the sample rate of the
>> wav file I'm using for testing (with aplay) and iecset. I'd expect that
>> aplay would set the sample (locking) rate of the spdif interface to the
>> sample frequency as the wav file, what is the use of iecset (rate) then?
>> I am using hw:0,0 to really avoid software resampling.

> Well, still I didn't write what you did and what you got...

Spotted well, it takes some time to recreate the complete test suite.

I will have a go once more with newer alsa libs/utils and then submit
the results. I wasn't too eager before because I didn't get any reply
for weeks...

>>>>>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
>>>>>> I cannot make work properly at all (only one channel is output, large
>>>>>> chunks are discarded, much much clipping).
>>>>> The first PCM device is for the multi-output PCM.  It's for both
>>>>> analog and digital.  The dedicated SPDIF is the secondary one.
>>>> But why does the second interface gives _some_ (although wrong) output
>>>> on my spdif output then?
>>> No idea, possibly wrong parameters are passed.
>> By whom or what? Actually I don't care that much, but it looks like a
>> bug to me.
> Possibly.  But too little information to analyze.

I think you're misunderstanding me here.

aplay -Dhw:0,0 sample.wav gives valid sound through spdif (though
limited), but aplay -Dhw:0,1 gives garbage on the same spdif output.
That doesn't look like an issue of aplay or the alsa lib, but a driver
issue.

>> [ rate bitfields in proc #codec# output ]
> Try HG version, and you'll see what they mean better.

The driver version in the kernel is kind of recent, so I really doubt
that. If you can give me a pointer to a file that has defines or enums,
that actually resolve to numbers, for this bitfield, I'd be obliged.


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Takashi Iwai]

At Wed, 29 Nov 2006 11:41:13 +0100,
Erik Slagter wrote:
> 
> >>>>>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
> >>>>>> I cannot make work properly at all (only one channel is output, large
> >>>>>> chunks are discarded, much much clipping).
> >>>>> The first PCM device is for the multi-output PCM.  It's for both
> >>>>> analog and digital.  The dedicated SPDIF is the secondary one.
> >>>> But why does the second interface gives _some_ (although wrong) output
> >>>> on my spdif output then?
> >>> No idea, possibly wrong parameters are passed.
> >> By whom or what? Actually I don't care that much, but it looks like a
> >> bug to me.
> > Possibly.  But too little information to analyze.
> 
> I think you're misunderstanding me here.
> 
> aplay -Dhw:0,0 sample.wav gives valid sound through spdif (though
> limited), but aplay -Dhw:0,1 gives garbage on the same spdif output.
> That doesn't look like an issue of aplay or the alsa lib, but a driver
> issue.

Ok, now I get to know about your tests, which program you used :)
Still I don't know what is sample.wav, though.  It's 48kHz?
You can try -Dspdif, too, BTW.

There shouldn't be much difference between hw:0,0 and hw:0,1 regarding
SPDIF setup.  Build with --with-debug=detect, and see the kernel
messages whether the driver sets different parameters to the digital
audio-output widget.

Also, you can compare the proc file content between two states,
i.e. during aplay -Dhw:0,0 and -Dhw:0,2.

In addition, check the parameters printed via aplay -v option to see
whether they are identical.

> >> [ rate bitfields in proc #codec# output ]
> > Try HG version, and you'll see what they mean better.
> 
> The driver version in the kernel is kind of recent,

Not recent enough.  Try HG version, really.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 1845 bytes --]

Takashi Iwai wrote:

>> aplay -Dhw:0,0 sample.wav gives valid sound through spdif (though
>> limited), but aplay -Dhw:0,1 gives garbage on the same spdif output.
>> That doesn't look like an issue of aplay or the alsa lib, but a driver
>> issue.

> Ok, now I get to know about your tests, which program you used :)
> Still I don't know what is sample.wav, though.  It's 48kHz?
> You can try -Dspdif, too, BTW.

It's really really simple.

I generated wav files from /dev/zero using sox, with sample rates of 32
khz, 44.1 khz, 48 khz and 96 khz. Then I used simply aplay to play them all.

aplay -Dhw:0,0 test.wav

The wavs containing 44.1 and 48 khz play without a problem, BUT when
playing the 44.1 khz file, my DAT recorder still says it 48 khz and it
looks the audio is resampled somewhere. The 32 khz and 96 khz give a
message about sample rate not being available and then aplay selects
44.1 khz instead.

Then I did the same using -Dhw:0,2 (in the latest alsa versions this has
become hw:0,1) and the result is exactly the same (same wavs, same spdif
output,same dat recorder) EXCEPT there is a lot of noise through the
sound. I cannot believe this is a feature... This looks more like a
channels/bits/rate mismatch: one channel has audio AND noise, the other
channel is silent.

> Also, you can compare the proc file content between two states,
> i.e. during aplay -Dhw:0,0 and -Dhw:0,2.
> In addition, check the parameters printed via aplay -v option to see
> whether they are identical.

This is interesting. The 44.1 khz wav file is played by aplay using 44.1
khz, the pcm0p/sub0/hw_params also says it's 44.1 khz, still the DAT
recorder remains locked at 48 khz. Looks like at some point alsa fails
to set the actual output sample rate (spdif modulation)?

There is no difference in this behaviour wether I am using hw:0,0 or hw:0,2


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 1776 bytes --]

Takashi Iwai wrote:

>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
>> I cannot make work properly at all (only one channel is output, large
>> chunks are discarded, much much clipping).

> The first PCM device is for the multi-output PCM.  It's for both
> analog and digital.  The dedicated SPDIF is the secondary one.

I've been experimenting at large yesterday, and I now I finally
understand what you mean by this sentence.

It appears that if you send output to hw:0,0 which comprises of
two-channel data AND the iec958 enable control is set to on, then the
hw:0,1 is also opened (returns "busy" on open) and the sound is sent to
that device simultaneously. If the amount of channels is other than 2,
then this scheme is not followed, and the secondary interface remains
available. If the iec958 enable control is set to false, none of the
hw:0,0 or hw:0,1 output data to spdif.

Is this intended behaviour? I think it is very very confusing. IMHO the
alsa lib has enough features to copy sound to both devices, when the
user actually wants that. And I don't! hw:0,0 should simply output to
analog en hw:0,1 to digital... At least the user should be able to
choose the behaviour using the iec958 enable control, being "on"
implementing the current "copying" behaviour and otherwise simply
exposing two independent devices.

Oh and BTW the bug I reported earlier on, with the hw:0,1 (digital)
interface giving noise in one channel, appears to be really a bug, with
a workaround, so it might be a simple one to resolve; if you output
sound to the device and toggle the iec958 control a few times, the noise
goes away and the interface works OK. Looks like an initialisation
problem to me...

This is all with vanilla linux 2.6.19 (alsa 1.0.13).

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: SPDIF/IEC958 sample rate on HDA/ALC882

[Erik Slagter]

Takashi Iwai wrote:

>> Maybe I am using the wrong "hw", there is also a "hw:0,2" device, which
>> I cannot make work properly at all (only one channel is output, large
>> chunks are discarded, much much clipping).

> The first PCM device is for the multi-output PCM.  It's for both
> analog and digital.  The dedicated SPDIF is the secondary one.

I've been experimenting at large yesterday, and I now I finally
understand what you mean by this sentence.

It appears that if you send output to hw:0,0 which comprises of
two-channel data AND the iec958 enable control is set to on, then the
hw:0,1 is also opened (returns "busy" on open) and the sound is sent to
that device simultaneously. If the amount of channels is other than 2,
then this scheme is not followed, and the secondary interface remains
available. If the iec958 enable control is set to false, none of the
hw:0,0 or hw:0,1 output data to spdif.

Is this intended behaviour? I think it is very very confusing. IMHO the
alsa lib has enough features to copy sound to both devices, when the
user actually wants that. And I don't! hw:0,0 should simply output to
analog en hw:0,1 to digital... At least the user should be able to
choose the behaviour using the iec958 enable control, being "on"
implementing the current "copying" behaviour and otherwise simply
exposing two independent devices.

Oh and BTW the bug I reported earlier on, with the hw:0,1 (digital)
interface giving noise in one channel, appears to be really a bug, with
a workaround, so it might be a simple one to resolve; if you output
sound to the device and toggle the iec958 control a few times, the noise
goes away and the interface works OK. Looks like an initialisation
problem to me...

This is all with vanilla linux 2.6.19 (alsa 1.0.13).

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [PATCH] Re: iec958 switch uneffective while playing ac3 stream

[Dag Lem]

Takashi Iwai <tiwai@suse.de> writes:

[...]

> The fix is already in HG tree, so please test the latest HG version
> to confirm whether it's fixed.

I finally got around to test the code in the HG tree.

The S/PDIF output still works perfectly on the ALC882M. I ran PCM
tests using all available frame rates (44.1kHz, 48kHz, 96kHz, 192kHz).
I also tested AC3 (at 48kHz) and DTS (at 44.1kHz and 48kHz).

Good work! That goes for Dominique as well, of course :-)

The only fly in the ointment for the average user will be, I think,
that HDA-Intel.pcm.default is using dmix. This effectively cuts most
non-experts off from using anything but 48kHz, resulting in inferior
sound quality (and unavailability to play back 44.1KHz DTS over
S/PDIF) due to resampling.

Perhaps dmix could be configured with more than one destination frame
rate, so that resampling would only be used if absolutely necessary?
Just a thought.

-- 
Best regards,

Dag Lem