Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

snd_pcm_wait_nocheck - use more finer timeout for the the poll wait #228

Closed
takaswie opened this issue Oct 29, 2019 · 2 comments
Closed

Comments

@takaswie
Copy link
Member

Axfer calls polling system call(i.e. poll(2), epoll(7), select(7)) without explicit timeout when running for IRQ-based scheduling model. In a case that driver achieves to control sound hardware for periodical hardware IRQ, the call can return due to any event queued by the driver in hardware IRQ context. However, in a case that driver fails to control it, the call cannot return.

Especially, this situation easily occurs when developers work to support hardware newly. It's better to care for the situation.

How to reproduce:

  1. prepare sound hardware which driver fail to control for periodical hardware IRQ.
  2. execute axfer for the driver/hardware with options to:
  • use IRQ-based scheduling model: --sched-model=irq
  • use polling system call: without --test-nowait
  1. the running process blocks as a call of polling system call (defaultly poll(2) by snd_pcm_wait())
@takaswie takaswie changed the title axfer: call of polling system call never return when driver fails to queue any events due to the lack of hw IRQ context axfer: call of polling system call never return when driver fails to queue no period-wakeup event due to the lack of hw IRQ context Oct 29, 2019
@takaswie
Copy link
Member Author

I filed PR alsa-project/alsa-utils#31 .

However, even if merging the patchset, poll(2) system call is called without timeout inner alsa-lib. This occurs in cases that some alsa-lib PCM plugins (e.g. plug) is used which call below alsa-lib APIs internally:

  • snd_pcm_read_areas()
  • snd_pcm_write_areas()

These two APIs call poll(2) internally without explicit timeout (-1). Furthermore, even if returning due to emitted signal (errno = EINTR), poll(2) is called again in internal loop. This disables users to terminate runtime by SIGINT.

->snd_pcm_readi()
= snd_pcm_plugin_read1()
  ->snd_pcm_read_areas()
    ->__snd_pcm_wait_in_lock(timeout=-1)
      ->snd_pcm_wait_nocheck(timeout=-1)

->snd_pcm_readn()
= snd_pcm_plugin_read1()
  ->snd_pcm_read_areas()
    ->__snd_pcm_wait_in_lock(timeout=-1)
      ->snd_pcm_wait_nocheck(timeout=-1)

->snd_pcm_writei()
= snd_pcm_plugin_write1()
  ->snd_pcm_write_areas()
    ->snd_pcm_wait_nocheck(timeout=-1)

->snd_pcm_writen()
= snd_pcm_plugin_write1()
  ->snd_pcm_write_areas()
    ->snd_pcm_wait_nocheck(timeout=-1)
int snd_pcm_wait_nocheck(snd_pcm_t *pcm, int timeout)
{
    int err_poll;
    ...
    do {
        __snd_pcm_unlock(pcm);
        err_poll = poll(pfd, npfds, timeout);
        __snd_pcm_lock(pcm);

        if (err_poll < 0) {
                if (errno == EINTR && !PCMINABORT(pcm))
                        continue;
            return -errno;
        }

        if (!err_poll)
            break;
        ...
    } while (!(revents & (POLLIN | POLLOUT)));
    ...
}

@perexg
Copy link
Member

perexg commented Nov 5, 2019

The maximal timeout can be estimated for those callers wait callers. I agree that the timeout should be set to a more sane value, because we know the stream parameters (thus the real time timing).

@perexg perexg transferred this issue from alsa-project/alsa-utils May 16, 2022
@perexg perexg changed the title axfer: call of polling system call never return when driver fails to queue no period-wakeup event due to the lack of hw IRQ context snd_pcm_wait_nocheck - use more finer timeout for the the poll wait May 16, 2022
@perexg perexg closed this as completed in e2d9e41 May 3, 2023
perexg added a commit that referenced this issue May 3, 2023
Add possibility to return -EINTR instead waiting for the event. The
applications may want to handle -EINTR condition themselves.

BugLink: #228
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
perexg added a commit that referenced this issue May 3, 2023
Add possibility to return -EINTR instead waiting for the event. The
applications may want to handle -EINTR condition themselves.

BugLink: #228
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants