| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
And don't print an error if one couldn't be started when not requested.
|
| |
|
|
|
| |
The buffer-size config option now only specifies an additional mix ahead to
keep ready for audio requests, rather than a pretend period size.
|
| | |
|
| | |
|
| |
|
|
|
| |
This does basically no checking that the channel config is correct, but should
be good enough for when non-stereo modes are requested.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We should also add the port latency, but there's currently no way to ensure
it's synchronized with the ringbuffer (the ringbuffer will update before the
port latency gets updated).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few notes about it:
The OpenAL device's requested buffer metrics are ignored, and instead the
device will keep one JACK-sized buffer's worth of audio prepared for JACK's
next process request.
Output is restricted to 32-bit float stereo. Part of this is because JACK
requires a buffer size that's a power of 2 (measured in samples), and the
ringbuffer requires a buffer size that's a power of 2 (measured in bytes). A
channel count of 6 (5.1) or 7 (6.1) will not work without causing a sample to
split over the edge of the ringbuffer. Additioanlly, JACK doesn't provide
information about what channel configuration a device or set of ports has, so
there's no way to know what ports 3 and up map to (even the first two ports are
unknown, but assuming stereo seems to work well enough).
There is no device latency measurement (for AL_SOFT_source_latency) due to the
non-atomicity between the ringbuffer's read size and port latency. A method is
needed to ensure the ringbuffer's read size and port latency can both be
measured between the end of a JACK update cycle (when the port latency has been
updated with the newly-retrieved audio) and the following ringbuffer read
update.
|
| |
|
