From: Takashi Iwai <tiwai@suse.de>
To: Yogesh Soni <yksoni@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH]: No sound when using software based mmap support and dmix plugin
Date: Wed, 27 May 2015 17:28:48 +0200 [thread overview]
Message-ID: <s5ha8wq9gzz.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAHK=agvr7-Yvbns1GbbwbhbOiTh1P-NMjxTD6Fa9kC2O6fuJSA@mail.gmail.com>
At Thu, 21 May 2015 14:48:00 -0700,
Yogesh Soni wrote:
>
> Yes Takashi. You are right. Freewheeling mode doesn't necessarily mean that
> appl_ptr is invalid. I conveniently used stop_threshold check, to infer if
> dmix plugin is being used. I am definitely looking for a cleaner way to do
> this. Would there be any negative implications (performance or otherwise)
> of relying on xrun status?
Well, I'm not sure whether the XRUN state check is always performed
before pcm-indirect operations. If yes, then we can rely on it.
> The diff should contain bytes_to_copy, instead
> of a boolean value, right?
Yes.
thanks,
Takashi
> Thanks
> Yogesh
>
> On Wed, May 20, 2015 at 11:55 PM, Takashi Iwai <tiwai@suse.de> wrote:
>
> > At Tue, 19 May 2015 11:14:13 -0700,
> > Yogesh Soni wrote:
> > >
> > > Hi Takashi,
> > >
> > > Thanks for your reply. Please consider the following snippet from
> > > pcm-indirect.h. When using other plugins (like softvol), appl_ptr was
> > > updated correctly and below code worked well. In case of dmix, The
> > samples
> > > are never copied to substream because
> > > appl_ptr = rec->appl_ptr = diff = 0 --> rec->sw_ready = 0 .
> > >
> > > *snd_pcm_sframes_t diff = appl_ptr - rec->appl_ptr;*
> > > .....
> > > if (*diff*) {
> > > .......
> > > rec->sw_ready += (int)frames_to_bytes(runtime, diff);
> > > .......
> > > }
> > > while (rec->hw_ready < qsize &&* rec->sw_ready > 0*) {
> > > *copy(substream, rec, bytes);*
> > > }
> >
> > I see. But, the free wheeling mode doesn't mean that appl_ptr is
> > always invalid. It means nothing but we don't do any xrun checks and
> > keeps the stream running.
> >
> > So, instead of checking only the stop_threshold, how about to check if
> > it's in xrun, and then use it as diff?
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> > >
> > > Regards
> > > Yogesh
> > >
> > > On Tue, May 19, 2015 at 4:47 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > > At Wed, 13 May 2015 17:12:33 -0700,
> > > > Yogesh Soni wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I am trying to have dmix plugin work ( I succeeded) with the audio
> > card
> > > > > that does not have hardware mmap support and uses pcm_indirect
> > method to
> > > > > map software buffer for mmap feature.
> > > > >
> > > > > Most of the plugins were working quite well with mmap/pcm_indirect
> > combo.
> > > > > However, dmix plugin did not work (no sound). I debugged and realized
> > > > that
> > > > > appl_ptr in pcm_direct.h(snd_pcm_indirect_playback_transfer()) was
> > > > always 0
> > > > > and hence nothing got copied to slave pcm buffer. I then discovered
> > that
> > > > > dmix operates in freewheeling-mode..
> > > > >
> > > > > I have made a small workaround patch (I believe it can be cleaned
> > up) in
> > > > > case of free-wheeling mode, basically using sw_ready to hold bytes
> > that
> > > > > need to be copied. I used rec->sw_ready because it looked safest to
> > use
> > > > for
> > > > > this purpose. As a result of this patch, normally period_size bytes
> > are
> > > > > copied to pcm buffer every period and sound is playing smooth.
> > > > >
> > > > > I am a noob in alsa and linux in general. So, I would like your
> > opinion
> > > > on
> > > > > the patch. I would much prefer if I could write a patch that is
> > generic
> > > > and
> > > > > clean enough, so that it could be used by others. patch is attached.
> > > >
> > > > Thanks for reporting and the patch.
> > > >
> > > > So, what actually prevents working with the current code in the free
> > > > wheeling mode?
> > > >
> > > >
> > > > Takashi
> > > >
> > > [2 <text/html; UTF-8 (quoted-printable)>]
> > >
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
prev parent reply other threads:[~2015-05-27 15:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHK=aguXV_4zK+=FBmrMKZrVmBPSMoCdVvdK_P9i0HQVJXPcrw@mail.gmail.com>
2015-05-19 11:47 ` [PATCH]: No sound when using software based mmap support and dmix plugin Takashi Iwai
2015-05-19 18:14 ` Yogesh Soni
2015-05-21 6:55 ` Takashi Iwai
2015-05-21 21:48 ` Yogesh Soni
2015-05-27 15:28 ` Takashi Iwai [this message]
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=s5ha8wq9gzz.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=yksoni@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox