Joerg-Cyril.Hoehle@t-systems.com wrote:
UC1 Intermittent Mouse Clicks An app may use the winmm API as follows:
- open the device
- from time to time, e.g. on mouse clicks, send wave data.
The requirements are:
R1 Nothing (or silence) is to be played when the app submits no data. R2 Once the app submits data, it should play ASAP.
That is the app's view on it. It seems to translate to silence_threshold=0 and silence_size=boundary, doesn't it?
This translates to stop_threshold=buffer_size and start_threshold=1. (Please note that a very small start_threshold increases the possibility of an underrun because it becomes more likely that the sound card immediately reads all valid samples.)
UC2 Video I've not much to say here because I basically ignore how apps synchronize audio with video. GetPosition returns "the stream position of the sample that is currently playing through the speakers". This begs for snd_pcm_delay, not avail_update.
Yes.
However, does that documentation actually make a distinction between the last sample that has been read from the buffer and the sample being played?
R3 Wine must offer access to several sound cards if available.
It is not easy to enumerate available sound devices.
It's possible to enumerate hardware devices, but this does not give you software-implemented devices like PulseAudio or Bluetooth.
I'd suggest to have a default device ("default") and one device for each hardware sound card ("default:x", where x is the card index, but some people write a custom .asoundrc where this doesn't work), with the possibility of adding other device names.
R4 Try and find hw/sw_params that work with the "default" device as well as individual cards (hw:x or perhaps plughw:x).
The hw_params are hardware dependent; there is not set of values that is guaranteed to be available on all devices.
Unless you actually know that certain settings are possible, you should always use snd_hw_params_set_xxx_near/first/last.
mmdevapi has a notion of exclusive and shared modes. I expect shared mode to be asked with the "default" device (for mixing to work), and exclusive with others (e.g. 5:1 sound). OTOH, apps may also ask for the default device in exclusive mode, which is said to be granted if no other app is playing sound (much like I can grab hw:0 only when dmix has nothing to do).
There are some conventions about which devices are sharable, but those are not always true with some custom configurations.
I would be tempted to just ignore the exclusive/share flag.
R5 No samples are ever skipped. If late, play late. See R1/R2.
I've observed that "dmix"+"pulse" and the "hw:x" devices approach underruns radically differently. In case of a 10s underrun, the former silently skip over the next 10s worth of samples(!) -- if the app does not submit those *fast* to catch up, you'll hear no more sound! -- while the latter immediately write them to their HW buffer.
During an underrun, the device does not have valid samples to play. A hardware device just plays whatever currently is in the ring buffer; PulseAudio does not bother to mix samples that it knows would be wrong.
There is no guarantee about the actual output resulting from those 'missed' samples. You can set silence_threshold/size to force silence.
The continue-on-xrun mode is intended for situations where the overall timing of the running stream is important. After an xrun, you indeed have to write the 'missed' samples as fast as possible to catch up, until the relationship between written samples and elapsed time is back to a situation that looks as if no xrun has happened.
Configuring the device to stop on xruns seems to be a better fit for your requirements.
Regards, Clemens