All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Homann <jh@janhomann.de>
To: Clemens Ladisch <clemens@ladisch.de>, alsa-devel@alsa-project.org
Subject: Re: Too many snd_pcm_mmap_readi calls
Date: Wed, 07 May 2014 11:52:45 +0200	[thread overview]
Message-ID: <536A026D.1070104@janhomann.de> (raw)
In-Reply-To: <5369F684.7060502@ladisch.de>

Arg, i am sorry for the enormouse amount of errors in eight lines of
code. Is there any "Errors per line"-List? Maybe there is a new leader
by now.

I added the sleep to see the start of one while-loop in the strace
output. Not every function appears in the strace. Just to see where the
loop starts i added a function and sleep came into my mind first.
In my real function i am checking the return values of snd_pcm_wait and
snd_pcm_mmap_readi. The return value of snd_pcm_mmap_readi is used to
encode the amount of captured samples with opus.

In my opinion mmap_begin just tells the alsa-lib that someone is about
to access the buffer. With avail_update all buffer states (whatever they
are) are updated and mmap_readi gets the samples to
network_data.data_UC. After that, mmap_commit tells the alsa-lib that i
am ready with the buffer.
Maybe i am wrong with that. Ok, for sure i am wrong with that.

I am using mmap because of its good performance. Under normal condition
with snd_pcm_mmap_readi my program uses about 1% of cpu-time where
snd_pcm_readi uses about 75%.

Do you know a good tutorial about using mmap_readi?

Am 07.05.2014 11:01, schrieb Clemens Ladisch:
> Jan Homann wrote:
>> while(1) {
>>     sleep(1);
>>     snd_pcm_wait( pcm_handle, REC_BUFFER_ELEMENT_SIZE_MS + 10);
>>     snd_pcm_mmap_begin(pcm_handle, &my_areas, &offset, &frames);
>>     snd_pcm_avail_update ( pcm_handle );
>>     snd_pcm_mmap_readi( pcm_handle, network_data.data_UC, ALSA_READ_FRAMES);
>>     snd_pcm_mmap_commit(pcm_handle, offset, frames);
>> }
> The sleep will result in an overrun, which will throw off the timing
> of all following calls.
>
> You are not checking the return value of any of these functions.
>
> Why are you calling snd_pcm_avail_update?  And why are you doing this
> _after_ calling mmap_begin?
>
> You are ignoring the number of frames returned by mmap_begin.  This
> value could be smaller or larger than ALSA_READ_FRAMES.
>
> Why are you using mmap in the first place, when you don't even try to
> access the buffer directly?
>
>
> Regards,
> Clemens
>

  reply	other threads:[~2014-05-07  9:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07  7:18 Too many snd_pcm_mmap_readi calls Jan Homann
2014-05-07  9:01 ` Clemens Ladisch
2014-05-07  9:52   ` Jan Homann [this message]
2014-05-07 10:29     ` Jaroslav Kysela
2014-05-07 12:58     ` Clemens Ladisch
2014-05-13  7:25       ` Jan Homann

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=536A026D.1070104@janhomann.de \
    --to=jh@janhomann.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.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.