[alsa-devel] [PATCH]: No sound when using software based mmap support and dmix plugin

Takashi Iwai tiwai at suse.de
Wed May 27 17:28:48 CEST 2015


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 at 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 at 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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 


More information about the Alsa-devel mailing list