All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@aknet.ru>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: rate plugin issue
Date: Wed, 14 Nov 2007 23:10:02 +0300	[thread overview]
Message-ID: <473B561A.1050203@aknet.ru> (raw)
In-Reply-To: <s5hmytihlvo.wl%tiwai@suse.de>

Hi.

Takashi Iwai wrote:
> The problem is that the condition of poll() is indeed broken without
> the hack.  That is, it's no problem of snd_pcm_write_areas().
> snd_pcm_write_areas() just calls snd_pcm_wait(), which calls nothing
> but poll().  If your program calls poll() by itself, you would see the
> similar problem.
Yes. But I am not sure how should
it behave. For example, if the prog
sets avail_min=1, then it should
expect the snd_pcm_wait() to no longer
work. But I think the write() should
not be affected. Yes, snd_pcm_write_areas()
just calls snd_pcm_wait(), but should it?
Should write() depend on avail_min, or
only snd_pcm_wait() should?
If write() should depend on avail_min
(which doesn't look logical to me), then
this does imply mpg123 is doing the wrong
thing by setting avail_min=1? And so,
what would be the fix?

> True, it should be fixed in a better way.
Unfortunately, I have no idea how's the
better fix should look like.
My patch implements exactly the logic
I had in mind: leave snd_pcm_wait() to
depend on avail_min, but make writei()
to not depend on it (use period_size
instead). Since you don't agree with that
logic, please let me know what logic you
prefer.
Furthermore, as you said earlier, avail_min
doesn't really work as expected. It gets
"rounded" to period_size anyway, because
that's where the interrupt arrives. Taking
that into account, I can propose the following:
deprecate avail_min and always set it to
period_size, no matter what the program
thinks. That will pretty much return the
old behaveour (the hack), although this
time - without the underruns.
But I don't suppose you are going to like
also this approach. :)

> BTW, could you provide a bit more information how to reproduce the
> bug?
Simply play some mp3 with mpg123, run "top".

> (Or, a test-case code would be best, as you know  ;) 
Well, stripping down the mpg123 code is
not a rocket science, I can do that. But
I am a bit busy at the moment, this will
have to wait a few days. But I think there
are really no problems reproducing it. :)

  reply	other threads:[~2007-11-14 20:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-12  8:01 rate plugin issue Takashi Iwai
2007-11-12 19:25 ` Stas Sergeev
2007-11-13  3:20   ` Takashi Iwai
2007-11-14 20:10     ` Stas Sergeev [this message]
2007-11-15  6:51       ` Takashi Iwai
2007-11-17 14:59         ` Stas Sergeev
2007-11-19 11:09           ` Takashi Iwai
2007-11-19 21:09             ` Stas Sergeev
2007-11-20  6:31               ` Takashi Iwai
2007-12-18 15:43                 ` Timur Tabi
2007-12-19 12:50                   ` Takashi Iwai
2007-11-13 11:04   ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=473B561A.1050203@aknet.ru \
    --to=stsp@aknet.ru \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.