On Wed, 08 Aug 2007 13:28:12 +0200, Jacob Meuser wrote:
> On Fri, Aug 03, 2007 at 08:06:08PM +0200, Tim van der Molen wrote:
>
> > > I looked over esound, and the following patch is all I can see that
> > > could even remotely be a problem with the audio interface.
> >
> > I tested your patch using ogg123 and libao's esd module.
> >
> > The stuttering is almost completely gone, but ogg123 has problems to
> > start playing music.
> >
> > If I run ogg123, its time counter counts very fast for a while.
> > Meanwhile, I hear no sound. At some point, the time count is normal and
> > I hear the music stuttering for a moment, but after that it is fine. The
> > music stutters very seldomly.
> >
> > The duration of the `fast time count' depends on the time I haven't used
> > esound. The longer the time between two ogg123 invocations, the longer
> > the fast time count goes on. Waiting 10 seconds results in the fast time
> > count going to ~ 6 seconds; waiting ~ 5 minutes results in the fast time
> > count going to ~ 2.5 minutes.
>
> I think I finally figured out what's happening here.
>
> esound quits sending data to the audio device.
>
> audio(4) says that if you let the buffer run out, then you
> have to "catch up" before it will start playing back, unless
> you are in AUMODE_PLAY_ALL mode, and this is indeed enforced
> in the audio layer.
>
> I don't know if previous versions of esound sent silence to
> /dev/audio instead of pausing, or what, but 0.2.38 definitely
> quits sending audio data.
>
> this fixes the problem where clients "skip" through the
> first bit of playback, length of skip depending on time
> since esd's last activity (since it's trying to "catch up").
Yes, this problem is now fixed.
> it may also fix some "crackling" which could be produced by
> quick starts and stops because of timing discrepencies, which could
> happen if esound is not quite correct in it's delay calculations, or
> if the audio device is not actually consuming data at the rate it
> should. in such a case, the audio layer will pad in some silence
> to keep things smooth in AUMODE_PLAY_ALL mode.
With ogg123 there is almost no crackling/stuttering, just like last
time.
With audacious there is some occasional crackling/stuttering during
playback. There also is some stuttering when resuming after having
paused playback and when seeking through a song.
cmus[1] has the same problems as audacious, although the
crackling/stuttering during playback is more subtle. Further, there is
some stuttering when starting to play a song.
I'm running -current from 4 August and thus I don't have your last
commit to sys/dev/audio.c. Would that make any difference?
> I'm also including the previous patch I sent to ports@, because
> it was reported to help. however, it could actually work against
> the AUMODE_PLAY_ALL change, because there could possibly be
> fewer times padding will happen (but then there should also
> be less time when it need to be padded as well ...). if this
> patch in it's entirety does not fix the crackling, please try
> again without the last chunk.
With all three audio players, esound produces less crackling with the
full patch than with the partial patch.
Regards,
Tim
[1] An audio player that can use libao's esd module. It's not in ports.
I have submitted a port for it here:
<http://marc.info/?l=openbsd-ports&m=118590082416878&w=2>.
