| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
JACK2 will print error messages to stderr if it fails to connect to a server.
Users who don't normally use JACK but have the client lib installed will get
those messages even though OpenAL Soft will continue on to find a working
backend without trouble. So to avoid it, set an error message handler that'll
log them as warnings.
This isn't that great because there's no way to tell whether the error messages
are due to the server not running, or some other problem. And it resets the
callback to the default afterward even if it may have been set to something
else before. JACK2, which is what needs this workaround in the first place,
doesn't export the jack_error_callback pointer to properly save and restore it.
|
| | |
|
| |
|
|
|
|
| |
This will also allow backends to better synchronize the tracked clock time with
the device output latency, without necessarily needing to lock if the backend
API can allow for it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
