Created attachment 56624 [details] [review]
padsp-wait-for-context-initialization-in-ioctl-SNDCT.patch

Patch seems to fix error for me.
We just wait until context initializes in io actions.

This looks a bit odd. fd_info_new(), which is called from dsp_open(), only returns when the context is READY.

(In reply to comment #2)
> This looks a bit odd. fd_info_new(), which is called from dsp_open(), only returns when the context is READY.

Right. Let's consider the following code:

dsp_open calls:
    fd_info_new()
    ...
    i->io_event = api->io_new(api, i->thread_fd, i->io_flags, io_event_cb, i);

Before any IO occurs the state s READY, and it's seen in trace, but later.
When io occurs 'io_event_cb' is triggered (callback called asynchronously,
right?)

Let's looks at where it does there:
io_event_cb:
    // no idea what it does, but looks like it unblocks clients
    pa_threaded_mainloop_signal(i->mainloop, 0); 

    // and then starts actual stream initialization
    if (flags & PA_IO_EVENT_INPUT) {
        if (!i->play_stream) {
            if (create_playback_stream(i) < 0)

create_playback_stream:
    // stream _DROPS_ initialization state down to: PA_STREAM_UNCONNECTED and then to PA_STREAM_CREATING
    i->play_stream = pa_stream_new(i->context, stream_name(), &i->sample_spec, NULL);

    pa_stream_set_state_callback(i->play_stream, stream_state_cb, i);
    pa_stream_set_write_callback(i->play_stream, stream_request_cb, i);
    pa_stream_set_latency_update_callback(i->play_stream, stream_latency_update_cb, i);

Let's make sure we get to this one for 2.0.

(In reply to comment #3)
> (In reply to comment #2)
> > This looks a bit odd. fd_info_new(), which is called from dsp_open(), only returns when the context is READY.
> 
> Right. Let's consider the following code:
> 
> dsp_open calls:
>     fd_info_new()
>     ...
>     i->io_event = api->io_new(api, i->thread_fd, i->io_flags, io_event_cb, i);
> 
> Before any IO occurs the state s READY, and it's seen in trace, but later.
> When io occurs 'io_event_cb' is triggered (callback called asynchronously,
> right?)

Yes, this registers an async callback when some I/O occurs.

> Let's looks at where it does there:
> io_event_cb:
>     // no idea what it does, but looks like it unblocks clients
>     pa_threaded_mainloop_signal(i->mainloop, 0); 

This is standard POSIX condition semantics -- the main thread is being told that some condition it is waiting for has been met.

>     // and then starts actual stream initialization
>     if (flags & PA_IO_EVENT_INPUT) {
>         if (!i->play_stream) {
>             if (create_playback_stream(i) < 0)
> 
> create_playback_stream:
>     // stream _DROPS_ initialization state down to: PA_STREAM_UNCONNECTED and
> then to PA_STREAM_CREATING
>     i->play_stream = pa_stream_new(i->context, stream_name(), &i->sample_spec,
> NULL);

This creates a new stream, doesn't mess with an existing stream.

This could go faster if you have some sort of quick test case for me to reproduce the issue locally.

Dropping as 2.0 blocker, but let's continue pinning down the actual problem

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/490.