Kernel people: is poll() less effective than using SND_PCM_ASYNC and a signal handler for low-latency sound? I'm guessing it is, but there
at the risk of endlessly repeating myself, SIGIO is basically useless. your handler executes in signal-handling context, and can do very, very little. not even all system calls are legal in this context. SIGIO is basically a "poor man's thread system", and not much more.
also, poll wakes a task quicker than a signal. this is easy to establish empirically. from a theoretical perspective, signal handling is a much more complex situation that simply continuing on with whatever function was blocked.
--p
According to the alsa documentation, SND_PCM_ASYNC handlers use SIGIO.
It is just as easy for me to create a thread and do poll, so I could do that.
I think the best approach will probably be to re-write the wine DirectSound routines, so that when they wish to write to a particular place in the sound buffer, they do a call to the alsa driver to do the actual positioning of the write pointer (snd_pcm_rewind/forward), followed by a write.
All I then do is turn off XRUN detection on the hardware buffer and let it freerun. "snd_pcm_sw_params_set_stop_threshold(pcm, sw_params, -1 )" turns off xruns.
Maybe I won't get that information from directsound.
I might need to find out how to control when the poll() returns.
If the period size is 1000, It would be nice if I could get it to return at say sample 800, so the mmap copying can happen just in time, before the DAC reaches the next period. This would give me sub-period latency, but I doubt that will work due to scheduling latencies etc.
I probably have to initially write 2 periods to the buffer, so that when the poll() returns, I will be writing to period 3, when the DAC is just reaching the start of period 2.
Due to scheduling latencies, I think I will write 2 periods on each poll() and then do a period rewind, so that if there is a scheduling latency, the sound card will be playing fairly accurate samples.
I just wish DirectSound would be able to tell us if it has changed the sound buffer at all. I hope this will be possible. It might not if the application does memcopies directly into the sound buffer without telling direct sound what it did.
If I can get Direct Sound to tell us when it writes to the sound buffer and what it changes, I could get the poll() to only memcpy the sections of the buffer that Direct Sound changes.
The way DirectSound works, is it calles "GetPosition" evert 10ms and gets returned 2 pointers.
1) Playback Position (The Sample currently at the speakers, or more accurately, in the DAC.)
2) Write Position. (The sample with the lowest latency that DirectSound could still re-write to now and it would reach the speakers.)
Normally this equals the start of the next period's position.
These pointers are pointers into the ring buffer using an offset from the beginning of the ring buffer.
I just hope the application tells direct sound what it is doing with the ring buffer. I will just have to investigate more.
I have already found out that Direct Sound tries to do multi open on the sound card, so we will be having multiple channels to mmap copy over on each poll if we use a sound card that handles multiopen. This could start to get quite complicated. :-)
Summary: -
I think I will work on the simple poll() approach first, instead of SND_PCM_ASYNC, with it outputting one period at a time.
Cheers James
------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
