https://bugs.freedesktop.org/show_bug.cgi?id=45643
--- Comment #5 from Arun Raghavan <[email protected]> 2012-03-15 00:02:14 UTC --- (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. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are the assignee for the bug. _______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
