[alsa-devel] snd-es1968 capture broken
Good day.
Capture is broken on snd-es1968, at least if it is driving a ES1970MS-3D (ESS Canyon 3D). The captured stream is "stuttering" like mad.
Kernel 2.6.20 (ALSA 1.0.14-rc1) with alsa-lib 1.0.11 (my distribution's version). Does not happen with a CS4236 in the same machine and same software version(s).
Don't know if this driver has a specific maintainer. If needed I guess I can try to pin it down to some change. I hardly use capture on this card but it wasn't always broken...
Rene.
At Mon, 26 Mar 2007 14:52:13 +0200, Rene Herman wrote:
Good day.
Capture is broken on snd-es1968, at least if it is driving a ES1970MS-3D (ESS Canyon 3D). The captured stream is "stuttering" like mad.
Kernel 2.6.20 (ALSA 1.0.14-rc1) with alsa-lib 1.0.11 (my distribution's version). Does not happen with a CS4236 in the same machine and same software version(s).
Don't know if this driver has a specific maintainer. If needed I guess I can try to pin it down to some change. I hardly use capture on this card but it wasn't always broken...
What format and channels did you try? The capture on maestro2 is troublesome because it uses non-interleaved format for capture. So, recording a mono stream may still work.
Also, to be sure, could you try the capture via oss emulation?
thanks,
Takashi
On 03/26/2007 03:00 PM, Takashi Iwai wrote:
Capture is broken on snd-es1968, at least if it is driving a ES1970MS-3D (ESS Canyon 3D). The captured stream is "stuttering" like mad.
Kernel 2.6.20 (ALSA 1.0.14-rc1) with alsa-lib 1.0.11 (my distribution's version). Does not happen with a CS4236 in the same machine and same software version(s).
Don't know if this driver has a specific maintainer. If needed I guess I can try to pin it down to some change. I hardly use capture on this card but it wasn't always broken...
What format and channels did you try?
-f cd and -f dat
The capture on maestro2 is troublesome because it uses non-interleaved format for capture. So, recording a mono stream may still work.
Yes, you're right. All combinations of -f U8/S16_LE and -r 44100/48000 work as long as -c is 1. With -c 2 the stutter is there.
Also, to be sure, could you try the capture via oss emulation?
Works fine, no stuttering:
sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp foo.wav
Rene.
At Mon, 26 Mar 2007 15:40:00 +0200, Rene Herman wrote:
On 03/26/2007 03:00 PM, Takashi Iwai wrote:
Capture is broken on snd-es1968, at least if it is driving a ES1970MS-3D (ESS Canyon 3D). The captured stream is "stuttering" like mad.
Kernel 2.6.20 (ALSA 1.0.14-rc1) with alsa-lib 1.0.11 (my distribution's version). Does not happen with a CS4236 in the same machine and same software version(s).
Don't know if this driver has a specific maintainer. If needed I guess I can try to pin it down to some change. I hardly use capture on this card but it wasn't always broken...
What format and channels did you try?
-f cd and -f dat
The capture on maestro2 is troublesome because it uses non-interleaved format for capture. So, recording a mono stream may still work.
Yes, you're right. All combinations of -f U8/S16_LE and -r 44100/48000 work as long as -c is 1. With -c 2 the stutter is there.
Also, to be sure, could you try the capture via oss emulation?
Works fine, no stuttering:
sox -t ossdsp -w -s -r 44100 -c 2 /dev/dsp foo.wav
Then it might be some bugs in alsa-lib deinterleving code. Please try the latest alsa-lib first, then let's chase the bug.
Takashi
On 03/26/2007 03:49 PM, Takashi Iwai wrote:
[ snd-es1968 capture stuttering on es1970ms-3d ]
Please try the latest alsa-lib first, then let's chase the bug.
Upgraded everything to 1.0.14-rc3 (weeee, db gains -- no more thumbing datasheets to get at the 0 dB levels) and the problem is still present unfortunately.
Rene.
On 03/26/2007 05:15 PM, Rene Herman wrote:
[ snd-es1968 capture stuttering on es1970ms-3d ]
Please try the latest alsa-lib first, then let's chase the bug.
Upgraded everything to 1.0.14-rc3 (weeee, db gains -- no more thumbing datasheets to get at the 0 dB levels) and the problem is still present unfortunately.
To check it's not hardware, I tried on Windows (98) where it works fine. It does happen in Linux with Line, CD and Mix capture sources. Using arecord -M does not help, nor removing SNDRV_PCM_INFO_BLOCK_TRANSFER from snd_es1968_capture (just as some various datapoints).
Unfortunately I don't a different snd-es1968 card to test with; this is a TerraTec DMX.
Rene.
At Tue, 27 Mar 2007 00:59:27 +0200, Rene Herman wrote:
On 03/26/2007 05:15 PM, Rene Herman wrote:
[ snd-es1968 capture stuttering on es1970ms-3d ]
Please try the latest alsa-lib first, then let's chase the bug.
Upgraded everything to 1.0.14-rc3 (weeee, db gains -- no more thumbing datasheets to get at the 0 dB levels) and the problem is still present unfortunately.
To check it's not hardware, I tried on Windows (98) where it works fine. It does happen in Linux with Line, CD and Mix capture sources. Using arecord -M does not help, nor removing SNDRV_PCM_INFO_BLOCK_TRANSFER from snd_es1968_capture (just as some various datapoints).
Unfortunately I don't a different snd-es1968 card to test with; this is a TerraTec DMX.
OK, then this is very likely a bug in alsa-lib plug layer. Although I'm the maintainer, I have no longer board working on my systems, so it's a big tough to debug right now. I'll try to reproduce / emulate with other systems...
Takashi
On 03/27/2007 04:02 PM, Takashi Iwai wrote:
OK, then this is very likely a bug in alsa-lib plug layer. Although I'm the maintainer, I have no longer board working on my systems, so it's a big tough to debug right now. I'll try to reproduce / emulate with other systems...
Given a relative unfamiliarity with the "inner alsa innards", I'm not too likely to find it but if it's hard for you, give me a few days and I'll try. Any and all "look here and there" pointers welcome...
Rene.
On 03/27/2007 04:09 PM, Rene Herman wrote:
Given a relative unfamiliarity with the "inner alsa innards", I'm not too likely to find it but if it's hard for you, give me a few days and I'll try. Any and all "look here and there" pointers welcome...
As a first try, I tried a 2.6.10 kernel (alsa 1.0.6) coupled with 1.0.6 lib and utils but the problem is present there as well. Which is fairly odd, since I have a significantly more recently captured source which is fine; I guess I _might_ have had a cs46xx card installed then...
I described the problem as a "stutter" but maybe that's not the best description; it's a "ticking" sound behind/over the actual captured sound. It's hard to hear if the sound is correct other than that; if I keep the "Capture" control at 0 dB, it's very soft and when I start upping it, it starts distorting (which doesn't surprise me; I keep chip gains at max 0 dB almost religiously since they all distort).
With this one the sound's so distorted at max gain it's almost turned into white noise though. Mmm, I'll try on windows again (where as said the capture's okay) if that's actually expected...
Rene
At Tue, 27 Mar 2007 18:29:57 +0200, Rene Herman wrote:
On 03/27/2007 04:09 PM, Rene Herman wrote:
Given a relative unfamiliarity with the "inner alsa innards", I'm not too likely to find it but if it's hard for you, give me a few days and I'll try. Any and all "look here and there" pointers welcome...
As a first try, I tried a 2.6.10 kernel (alsa 1.0.6) coupled with 1.0.6 lib and utils but the problem is present there as well. Which is fairly odd, since I have a significantly more recently captured source which is fine; I guess I _might_ have had a cs46xx card installed then...
I described the problem as a "stutter" but maybe that's not the best description; it's a "ticking" sound behind/over the actual captured sound. It's hard to hear if the sound is correct other than that; if I keep the "Capture" control at 0 dB, it's very soft and when I start upping it, it starts distorting (which doesn't surprise me; I keep chip gains at max 0 dB almost religiously since they all distort).
With this one the sound's so distorted at max gain it's almost turned into white noise though. Mmm, I'll try on windows again (where as said the capture's okay) if that's actually expected...
I vaguely remember that there is a problem regarding the buffer size alignment. One difference from OSS is that OSS accepts only power-of-2 buffer / period sizes. Could you check arecord with a buffer and sizes of power-of-2 via --buffer-size and --period-size options?
You can find a commented-out line in snd_es1968_capture_open(), BTW. IIRC, this didn't work...
Takashi
On 03/28/2007 12:02 PM, Takashi Iwai wrote:
I vaguely remember that there is a problem regarding the buffer size alignment. One difference from OSS is that OSS accepts only power-of-2 buffer / period sizes. Could you check arecord with a buffer and sizes of power-of-2 via --buffer-size and --period-size options?
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
You can find a commented-out line in snd_es1968_capture_open(), BTW. IIRC, this didn't work...
It does not...
Thanks, Rene
On 03/28/2007 12:43 PM, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
Rene.
On 03/28/2007 12:43 PM, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
Rene.
At Wed, 28 Mar 2007 13:03:51 +0200, Rene Herman wrote:
On 03/28/2007 12:43 PM, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
You can try snd_pcm_hw_constraint_pow2() there. But, IIRC, power-of-two constraint causes problems when you use buffer_time instead of buffer_size. Anyway, worth try once.
Takashi
On 03/28/2007 01:40 PM, Takashi Iwai wrote:
At Wed, 28 Mar 2007 13:03:51 +0200, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
You can try snd_pcm_hw_constraint_pow2() there.
Seems to work nicely! With the attached, a simple "arecord -f cd" works without problem (it then sets buffer_size 16384, period_size 4096) and seems to be settling on the nearest power of two if I pass something in for buffer_size manually.
But, IIRC, power-of-two constraint causes problems when you use buffer_time instead of buffer_size. Anyway, worth try once.
I don't seem to be experiencing problems there either;
command | buffer_size/period_size ------------------------------------------------------------ arecord -f cd --buffer-time 100000 | 4096/1103 arecord -f cd --buffer-time 150000 | 8192/1654 arecord -f cd --buffer-time 200000 | 16384/2205
These all work fine. With --period-time:
command | buffer_size/period_size ----------------------------------------------------------- arecord -f cd --period-time 20000 | 16384/882 arecord -f cd --period-time 35000 | 16384/1544 arecord -f cd --period-time 50000 | 16384/2205
All fine again. If I try upsetting the thing on purpose with large values, I get errors (from arecord, not in the sound).
As far as I'm concerned this seems good to go. Signed-off-by/Tested-by and all that.
Rene.
diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index dc84c18..8130a87 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -1617,6 +1617,8 @@ #if 0 snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 1024); #endif + snd_pcm_hw_constraint_pow2(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES); + spin_lock_irq(&chip->substream_lock); list_add(&es->list, &chip->substream_list); spin_unlock_irq(&chip->substream_lock);
At Wed, 28 Mar 2007 15:15:28 +0200, Rene Herman wrote:
On 03/28/2007 01:40 PM, Takashi Iwai wrote:
At Wed, 28 Mar 2007 13:03:51 +0200, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
You can try snd_pcm_hw_constraint_pow2() there.
Seems to work nicely! With the attached, a simple "arecord -f cd" works without problem (it then sets buffer_size 16384, period_size 4096) and seems to be settling on the nearest power of two if I pass something in for buffer_size manually.
But, IIRC, power-of-two constraint causes problems when you use buffer_time instead of buffer_size. Anyway, worth try once.
I don't seem to be experiencing problems there either;
command | buffer_size/period_size
arecord -f cd --buffer-time 100000 | 4096/1103 arecord -f cd --buffer-time 150000 | 8192/1654 arecord -f cd --buffer-time 200000 | 16384/2205
These all work fine. With --period-time:
command | buffer_size/period_size
arecord -f cd --period-time 20000 | 16384/882 arecord -f cd --period-time 35000 | 16384/1544 arecord -f cd --period-time 50000 | 16384/2205
All fine again. If I try upsetting the thing on purpose with large values, I get errors (from arecord, not in the sound).
As far as I'm concerned this seems good to go. Signed-off-by/Tested-by and all that.
OK, then it's good. I applied the fix together with cleanup of superfluous '#if 0's.
thanks,
Takashi
Rene.
[2 es1968_buffer_pow2.diff <text/plain (7bit)>] diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index dc84c18..8130a87 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -1617,6 +1617,8 @@ #if 0 snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 1024); #endif
- snd_pcm_hw_constraint_pow2(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES);
- spin_lock_irq(&chip->substream_lock); list_add(&es->list, &chip->substream_list); spin_unlock_irq(&chip->substream_lock);
participants (2)
-
Rene Herman -
Takashi Iwai