we *really* should not paper over underruns, as they require attention.
however, the previous attempt (c2a6b6e) caused an exception to be thrown
(see #130), which was a bit excessive, and was consequently reverted
(438e52e).
so instead we make the handling consistent with what we do in read():
return the verbatim -EPIPE in this case. this can be simply ignored, and
the next write will resume the stream, so this is mostly backwards-
compatible (the failing write will be discarded and would need
repeating, but that will just cause a skip after the interruption,
which does not seem particularly relevant).
as a drive-by, again stop using snd_pcm_recover(), as it still just
obfuscates the snd_pcm_prepare() call it does in the end.
in principle, the state is already available from info(), but that's a
rather heavy function for something one might want to query often.
a practical use case might be checking whether a playback stream is done
draining, for example.
for playback, this allows making sure that all written frames are
played, without using an external delay.
in principle, it's also usable for capture, but there isn't really a
practical reason to do so, as simply discarding excess captured frames
has no real cost.
the period count is just as important for playback latency as the period
size, so it makes no sense to have only one of them configurable.
as a drive-by, fix up the handling of periods in info() & dumpinfo().
for clarity, this includes docs which were previously omitted
(presumably) intentionally, but mark them as comments.
the getrec() and getmute() functions' docs are moved around, so they
appear in pairs with their set*() counterparts, like the *volume() ones
already did.
notably, this also fixes the docu of PCM_FORMAT_U8, which closes#104.
mention xruns, and rework the definition of periods: concentrate on
relevant information, and remove the misinformation about period size
reduction being not that bad (pedantically, an application could run
somewhat asynchronously to the interrupts by using some timer, and
therefore actually save some of the overhead, but why would one use a
small period size in the first place then?).
also, language and formatting fixes.
* First version documentation PCM.info() method.
* Add reference to documentation to docstring for PCM.info() method.
* Add extra fields to info dict:
card_no *index of card* integer (negative indicates device not associable with a card)
device_no *index of PCM device* integer
subdevice_no *index of PCM subdevice* integer
and update documentation accordingly.
Co-authored-by: Ronald van Elburg <Ronald@SoundAppraisal.eu>
* Use `pcmtype` keyword for range
Update methods that accept a `direction` argument (i.e.
capture/playback) to get this via positional _or_ keyword arguments.
Code using keyword arguments can be more robust; however the main reason
for this change is to prepare the way for an extra `units` argument to
many of these methods.
Update documentation to consistently use `pcmtype` instead of
a mixture of that and `direction`.
* Support units
SND_PCM_FORMAT_S24_LE and similar are for 24bit ints packed in 4-bytes each.
There is a similar family of formats for 3-bytes packed data (as stored in 24bit wave files).
This commit:
- adds S24_3LE, S24_3BE, U24_3LE, U24_3BE PCM formats to the alsaaudio.c
- updates documentation
- updates playwav.py to correctly play typical 24Bit PCM wave files
Closes#38