Bug 40125

Summary: Using the ALSA plug-in client, the end of short sounds are cut-off.
Product: PulseAudio Reporter: James <james>
Component: alsaAssignee: pulseaudio-bugs
Status: RESOLVED MOVED QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: lennart, mkbosmans
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: output from "pulseaudio -k; pulseaudio -vvvvv" during sound

Description James 2011-08-16 00:49:19 UTC
pulseaudio 0.9.23 on
Debian Wheezy/testing and
KDE4.6

Running klettres
 $ klettres --version
 Qt: 4.7.3
 KDE Development Platform: 4.6.5 (4.6.5)
 KLettres: 2.3

and configuring alsa with /etc/asound.conf as described at
 http://www.pulseaudio.org/wiki/PerfectSetup

The program klettres "speaks" the letters from different alphabets as short sounds.

If played through artsd, with a very short 8ms sound buffer and no auto-suspend, sounds are complete, as would be expected.  A longer sound buffer, or any recovery from auto-suspend, severely delays the start of a sound.

If played through pulseaudio with no alsa plugin, and with or without the pulseaudio server "connected", the end of the sounds are cut-off, and there is a "long" - over a second - and variable delay to the sound starting, especially if a sound is repeated before or during a previously triggered sound.

If played through artsd and esdcompat, there is no sound output at all.

If played through the alsa plugin, as configured above, the sound starts promptly, but the ends of the sound are cut-off.  The length of time cut-off seems to be relative to the _end_ of the sound, in the sense that a longer length of a sound is heard with a longer sound, but the end is still lost.  The length cut-off seems to be of some fixed length, around half a second to a second.  The cut-off is abrupt and ends with a soft "click/tick" noise.  The overall effect, of course, makes klettres practically unusable with pulseaudio.

Changing default-fragment-size-msec in /etc/pulse/daemon.conf makes no difference.

I am presuming that playing alsa through pulseaudio using the asound.conf configuration is the preferred pulseaudio set-up, so that approach should be made to "just work".


James
Comment 1 James 2011-08-18 12:54:26 UTC
Created attachment 50354 [details]
output from "pulseaudio -k; pulseaudio -vvvvv" during sound

Attached is the output from "pulseaudio -k; pulseaudio -vvvvv" for the time just during the sound event and the following suspend-on-idle.

James
Comment 2 James 2011-08-18 13:02:30 UTC
(In reply to comment #1)
> Created an attachment (id=50354) [details]
> output from "pulseaudio -k; pulseaudio -vvvvv" during sound
> 
> Attached is the output from "pulseaudio -k; pulseaudio -vvvvv" for the time
> just during the sound event and the following suspend-on-idle.
> 
> James

Forgot to add: the output in the attachment is _without_ any /etc/asound.conf.


James
Comment 3 Maarten Bosmans 2011-09-07 13:13:27 UTC
Can you verify were the problem lies by playing a short audio clip (e.g. a .wav file) through aplay (with the alsa pulse plugin) and paplay (direct pulse client), and report what works and what doesn't?
Comment 4 Arun Raghavan 2011-09-11 06:23:39 UTC
I can reproduce this locally with both aplay and paplay but only when the alsa-sink is coming out of suspend. I recall seeing this in the past as well. Not sure what might be causing this yet.
Comment 5 Arun Raghavan 2011-09-14 18:33:17 UTC
Annoyingly enough, I can't reproduce this problem here at the moment. Will try to keep an eye out for it.
Comment 6 James 2011-10-21 17:00:35 UTC
Playing-around some more with klettres, I notice that these "cut-off" sounds occur only with the Russian letters and syllables, and not with the English, British, or French letters and syllables, which are the only others that I have tried.  This suggests something different about the Russian sound files, or about the way that klettres is playing the sounds.  The Russian sound files play normally with paplay. 

Maybe the Russian sounds are "broken"?  Or maybe they cause problems for pulseaudio?  Or maybe they cause problems for klettres?

The sound files are all ogg encoded, and are available at

 http://files.kde.org/edu/klettres/


James
Comment 7 James 2011-10-23 11:38:16 UTC
I've also just found there is a problem playing some of the Ukrainian sounds, but the pattern is different.  Most of the sounds play normally, one of the sounds is "cut-off", and several of the sounds cannot be heard at all in klettres, though they play just fine through paplay.  Specifically, the sounds for м н and ж cannot be heard at all in klettres, and the sound for й is "cut-off", as with the Russian sounds.

I would also mention that I am playing sound through the Intel HDA and an Analog Devices AD1981 codec, now with pulseaudio Version: 1.0-4.  And, I've opened bug 284655 on the KDE Bug Tracking System, https://bugs.kde.org/show_bug.cgi?id=284655

Any suggestions how to determine if this is a KLettres bug or a KDE4 bug or an ALSA bug or a PulseAudio bug?  Or something in the PulseAudio API documentation that needs clarification?


James
Comment 8 James 2011-10-23 11:58:39 UTC
Hmm - the sound for й, uk/alpha/yot.ogg, I notice that this sounds the same when played through paplay as it does played through klettres.  I am not a Ukrainian speaker, so I do not know if this is the way it _should_ sound, but it sounds "cut-off" to me.

If this sound is actually being "cut-off" by paplay, then here is an example file that would show the problem using paplay, independently of klettres.  But then, I'm not sure about the sound itself.  To me, on my sound system, the sound seems to end immediately after the start of the "t" sound in "yot", with the end of the "t" sound missing, or maybe the entire "t" sound missing.


James
Comment 9 GitLab Migration User 2018-07-30 10:34:05 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/507.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.