Re: [PATCH]: No sound when using software based mmap support and dmix plugin

Re: [PATCH]: No sound when using software based mmap support and dmix plugin

[Takashi Iwai]

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

Re: [PATCH]: No sound when using software based mmap support and dmix plugin

[Yogesh Soni]

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);*
         }

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
>

Re: [PATCH]: No sound when using software based mmap support and dmix plugin

[Takashi Iwai]

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)>]
> 

Re: [PATCH]: No sound when using software based mmap support and dmix plugin

[Yogesh Soni]

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? The diff should contain bytes_to_copy, instead
of a boolean value, right?

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)>]
> >
>

Re: [PATCH]: No sound when using software based mmap support and dmix plugin

[Takashi Iwai]

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
>