Noise Problem with rate convert plugins

Noise Problem with rate convert plugins

[Andreas Rumpler]

Hello,

I'm new to this list.I hope someone could help me with a problem 
concerning the samplerate converter plugins of the alsa driver.

Firstly some facts about my application.

- Envy24 (VT1270) pci audio chip on a custom mainboard
- playback of sounds/music with different sample rates from 8kHz to 
48kHz (sample rate of the files)
- the hardware (Envy24 chip) must always run with 44.1kHz or 48kHz 
(selectable by user), because the audio is outputed by a DAC and SPDIF 
and the SPDIF clock must not be changed according to the sample rate of 
the files.
- Kernel is 2.6.22 and alsa is 1.0.14

So I'm using the samplerate (libsample rate based) plugin from the 
alsa-plugin package. Generaly it works very good.

My problem is:
Every time a playback is started a short plop noise is heard. The noise 
is on analog and SPDIF output. If I don't use the samplerate converter 
the noise is not heard at all. So it comes definitely from the rate 
converter plugin, I think. Changing  the quality level of the plugin 
don't solve the problem. I've also switched to the new Speex rate 
converter plugin. With this plugin there is no noise at the start of 
playback. But here I have trouble with awful noise at some rate 
conversions (6kHz(source) -> 48kHz(output); 11.025kHz -> 44.1kHz; 
22.05kHz -> 44.1kHz). So it's even worse than using the libsamplerate 
plugin. Finaly I've tried the libavcodec plugin, which is the worst 
according to noise.

Could any comment this problem, please?

This is my asound.conf:
##############################################
# Playback over Line-Out and SPDIF simultaniously as default

pcm.!default {
 type plug
 slave.pcm {
  type multi
  slaves.a.pcm "plughw:0,0"
  slaves.a.channels 2
  slaves.b.pcm "hw:0,1"
  slaves.b.channels 2
         bindings.0.slave a
         bindings.0.channel 0
         bindings.1.slave a
         bindings.1.channel 1
         bindings.2.slave b
         bindings.2.channel 0
         bindings.3.slave b
         bindings.3.channel 1
 }
 ttable.0.0 1
 ttable.1.1 1
 ttable.0.2 1
 ttable.1.3 1
}

pcm_slave.s1 {
 pcm default
 rate 44100
}

pcm_slave.s2 {
 pcm default
 rate 48000
}

pcm.rate_convert_44100 {
    type rate
    slave s1
    converter samplerate
}

pcm.rate_convert_48000 {
    type rate
    slave s2
    converter samplerate
}
#####################################################


Regards
Andreas Rumpler

Re: Noise Problem with rate convert plugins

[Takashi Iwai]

At Wed, 11 Jul 2007 17:41:21 +0200,
Andreas Rumpler wrote:
> 
> Hello,
> 
> I'm new to this list.I hope someone could help me with a problem 
> concerning the samplerate converter plugins of the alsa driver.
> 
> Firstly some facts about my application.
> 
> - Envy24 (VT1270) pci audio chip on a custom mainboard
> - playback of sounds/music with different sample rates from 8kHz to 
> 48kHz (sample rate of the files)
> - the hardware (Envy24 chip) must always run with 44.1kHz or 48kHz 
> (selectable by user), because the audio is outputed by a DAC and SPDIF 
> and the SPDIF clock must not be changed according to the sample rate of 
> the files.
> - Kernel is 2.6.22 and alsa is 1.0.14
> 
> So I'm using the samplerate (libsample rate based) plugin from the 
> alsa-plugin package. Generaly it works very good.
> 
> My problem is:
> Every time a playback is started a short plop noise is heard. The noise 
> is on analog and SPDIF output. If I don't use the samplerate converter 
> the noise is not heard at all. So it comes definitely from the rate 
> converter plugin, I think. Changing  the quality level of the plugin 
> don't solve the problem.

Could you try the patch below for alsa-plugins?


> I've also switched to the new Speex rate 
> converter plugin. With this plugin there is no noise at the start of 
> playback. But here I have trouble with awful noise at some rate 
> conversions (6kHz(source) -> 48kHz(output); 11.025kHz -> 44.1kHz; 
> 22.05kHz -> 44.1kHz). So it's even worse than using the libsamplerate 
> plugin. Finaly I've tried the libavcodec plugin, which is the worst 
> according to noise.

I can confirm the noise (like flanger effect) at 11025 -> 44100
conversion, too, but no at others.
Since 11024 -> 44100 works fine, it appears specific to quater or so.


Takashi

diff -r 83b528a8ca2e rate/rate_samplerate.c
--- a/rate/rate_samplerate.c	Mon Jun 04 15:23:44 2007 +0200
+++ b/rate/rate_samplerate.c	Thu Jul 12 15:36:38 2007 +0200
@@ -116,6 +116,7 @@ static void pcm_src_convert_s16(void *ob
 				const int16_t *src, unsigned int src_frames)
 {
 	struct rate_src *rate = obj;
+	unsigned int ofs;
 
 	rate->data.input_frames = src_frames;
 	rate->data.output_frames = dst_frames;
@@ -123,7 +124,12 @@ static void pcm_src_convert_s16(void *ob
 	
 	src_short_to_float_array(src, rate->src_buf, src_frames * rate->channels);
 	src_process(rate->state, &rate->data);
-	src_float_to_short_array(rate->dst_buf, dst, dst_frames * rate->channels);
+	if (rate->data.output_frames_gen < dst_frames)
+		ofs = dst_frames - rate->data.output_frames_gen;
+	else
+		ofs = 0;
+	src_float_to_short_array(rate->dst_buf, dst + ofs * rate->channels,
+				 rate->data.output_frames_gen * rate->channels);
 }
 
 static void pcm_src_close(void *obj)

Re: Noise Problem with rate convert plugins

[Andreas Rumpler]

[-- Attachment #1: Type: text/plain, Size: 3616 bytes --]

Dear Takashi,

Thanks for your response. I've tried the patch. It's seems be better 
now. But something seems still to be wrong.

At the start of the playback a short sequence seems to be outputed 
twice. Please have a look at the attached screenshot from my oszi. The 
screenshot shows playback of a sine with 440Hz.

The length of the sequence outputed twice is different for every 
samplerate conversion factor. If I go from 8kHz to 48kHz, it's 2.6 
millisec long. If I go from 22.025kHz to 48kHz, it's 900 microsec long. 
So it seems to be a fixed count of samples.

Regards
Andreas

Takashi Iwai schrieb:

>At Wed, 11 Jul 2007 17:41:21 +0200,
>Andreas Rumpler wrote:
>  
>
>>Hello,
>>
>>I'm new to this list.I hope someone could help me with a problem 
>>concerning the samplerate converter plugins of the alsa driver.
>>
>>Firstly some facts about my application.
>>
>>- Envy24 (VT1270) pci audio chip on a custom mainboard
>>- playback of sounds/music with different sample rates from 8kHz to 
>>48kHz (sample rate of the files)
>>- the hardware (Envy24 chip) must always run with 44.1kHz or 48kHz 
>>(selectable by user), because the audio is outputed by a DAC and SPDIF 
>>and the SPDIF clock must not be changed according to the sample rate of 
>>the files.
>>- Kernel is 2.6.22 and alsa is 1.0.14
>>
>>So I'm using the samplerate (libsample rate based) plugin from the 
>>alsa-plugin package. Generaly it works very good.
>>
>>My problem is:
>>Every time a playback is started a short plop noise is heard. The noise 
>>is on analog and SPDIF output. If I don't use the samplerate converter 
>>the noise is not heard at all. So it comes definitely from the rate 
>>converter plugin, I think. Changing  the quality level of the plugin 
>>don't solve the problem.
>>    
>>
>
>Could you try the patch below for alsa-plugins?
>
>
>  
>
>>I've also switched to the new Speex rate 
>>converter plugin. With this plugin there is no noise at the start of 
>>playback. But here I have trouble with awful noise at some rate 
>>conversions (6kHz(source) -> 48kHz(output); 11.025kHz -> 44.1kHz; 
>>22.05kHz -> 44.1kHz). So it's even worse than using the libsamplerate 
>>plugin. Finaly I've tried the libavcodec plugin, which is the worst 
>>according to noise.
>>    
>>
>
>I can confirm the noise (like flanger effect) at 11025 -> 44100
>conversion, too, but no at others.
>Since 11024 -> 44100 works fine, it appears specific to quater or so.
>
>
>Takashi
>
>diff -r 83b528a8ca2e rate/rate_samplerate.c
>--- a/rate/rate_samplerate.c	Mon Jun 04 15:23:44 2007 +0200
>+++ b/rate/rate_samplerate.c	Thu Jul 12 15:36:38 2007 +0200
>@@ -116,6 +116,7 @@ static void pcm_src_convert_s16(void *ob
> 				const int16_t *src, unsigned int src_frames)
> {
> 	struct rate_src *rate = obj;
>+	unsigned int ofs;
> 
> 	rate->data.input_frames = src_frames;
> 	rate->data.output_frames = dst_frames;
>@@ -123,7 +124,12 @@ static void pcm_src_convert_s16(void *ob
> 	
> 	src_short_to_float_array(src, rate->src_buf, src_frames * rate->channels);
> 	src_process(rate->state, &rate->data);
>-	src_float_to_short_array(rate->dst_buf, dst, dst_frames * rate->channels);
>+	if (rate->data.output_frames_gen < dst_frames)
>+		ofs = dst_frames - rate->data.output_frames_gen;
>+	else
>+		ofs = 0;
>+	src_float_to_short_array(rate->dst_buf, dst + ofs * rate->channels,
>+				 rate->data.output_frames_gen * rate->channels);
> }
> 
> static void pcm_src_close(void *obj)
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@alsa-project.org
>http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>  
>

[-- Attachment #2: Tek00001.gif --]
[-- Type: image/gif, Size: 18809 bytes --]

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

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

Re: Noise Problem with rate convert plugins

[Takashi Iwai]

At Mon, 16 Jul 2007 16:25:58 +0200,
Andreas Rumpler wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Dear Takashi,
> 
> Thanks for your response. I've tried the patch. It's seems be better 
> now. But something seems still to be wrong.
> 
> At the start of the playback a short sequence seems to be outputed 
> twice. Please have a look at the attached screenshot from my oszi. The 
> screenshot shows playback of a sine with 440Hz.

Hm, it's weird.  I'll check this later.

> The length of the sequence outputed twice is different for every 
> samplerate conversion factor. If I go from 8kHz to 48kHz, it's 2.6 
> millisec long. If I go from 22.025kHz to 48kHz, it's 900 microsec long. 
> So it seems to be a fixed count of samples.

BTW, a temporary fix against the problem with speex resampler was
committed to HG tree today.  It'll always use the interpolation, thus
more CPU time, but it's still not that bad at all.  Give it a try.


Takashi