gstreamer and vlc backends : Initial crackling when listening to a KDE sound event

[aCOSwt]

On Sunday 19 February 2012 22:11:12 Harald Sitter wrote:

> Does that also happen when you are using the device already? (listen
> to music or something).
> 
> This sounds a lot like the sounds is coming from device power saving
> (i.e. the waking up part).

Thank you for answering.

1/ I admit that the initial crackling sounds similar to what one can hear when 
switching on some audio device somewherein the chain but I do not think it is 
related to the "waking up part" because :
- The device I use for playback is always up because jack-audio-connection-kit 
is using it for playback and Jack gets a permanent client opened.
- The crackling occurs systematically with the vlc/gstreamer backends and 
absolutely never with the xine backend and absolutely never when using any 
non-phonon audio player.

I made several other experiments but with the gstreamer backend only because, 
because of https://bugs.kde.org/show_bug.cgi?id=255310 I cannot correctly 
select the output device I want when using phonon-vlc.

1/ If I ensure jack-audio-connection-kit is not running and select directly 
the audio device I want to output to in the playback list, having made sure 
that its sampling frequency is set to 48Khz (Identical to the SF of the test 
sound) then =>
The power of the initial crackling is significantly lowered.

SoJjack could be seen as the culprit or at least participating to the problem 
but another experiment tells that the root cause might be elsewhere :

2/ I ensure Jack is running, that the playback device is reset to Alsa-
Default, and that my sound device sampling rate is restored to 44.100 hz.
- Then I enter System-Settings/Application and System Notifications/Manage 
Notifications
- Then I select whatever event associated to some kde sound file (48Khz, ogg)
- If I play it back (acting on the button next to the filename field) then the 
initial crackling is there in its full power.
- Now if I change the sound file against whatever (44.100 hz, wav) then, when 
playing it back, I get no initial crackling. I mean NO initial crackling at 
all.

The exact same observation can be made if I play the sound file with 
dragonplayer.

To summarize, there would be somewhere with the [non-xine] backends some 
initial resampling problem when playing back to Alsa-Default, problem that 
Jack would amplify significantly.

BTW, it does not appear linked with the buffering capabilities of my Alsa-
Default, I tried several different values for buffer_size / period_size 
without noticing any difference.

Regards,

aCOSwt