Both input and output device were chosen with the same device number.
This is problematic as those numbers don't have to correspond.
Additionally the input device was named after the output device. This
commit adresses both issues by providing specific parameters for each
type.
This is a rebase of Wim Taymans patch to support the HSP headset role that has
somehow been forgotten. Original patch can be found at
https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-February/023242.html
Rebase and minor changes by Georg Chini.
In addition to the HSP Audio Gateway, also add support for the headset
role in the native bluetooth backend. In this role, pulseaudio is used as
headset.
In the headset role, we create source and sink to receive and send the samples
from the gateway, respectively. Module-bluetooth-policy will automatically load
loopback modules to link these to a sink and source for playback. Because this
makes the source the speaker and the sink the microphone, we need to reverse the
roles of source and sink compared to the gateway role.
In the gateway role, adjusting the sink volume generates a +VGS command to set
the volume on the headset. Likewise, receiving AT+VGS updates the sink volume.
In the headset role, receiving a +VGS should set the source volume and any
source volume changes should be reported back to the gateway with AT+VGS.
do...while not reachable, loop should try different ports in case EADDRINUSE is returned
Coverity ID: #1398161
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
The previous commit, "loopback: Initialize latency at startup and during
source/sink changes", was an old version of the patch that got
accidentally pushed instead of the last version. This commit does the
changes that were omitted when applying the old patch.
The current code does not make any attempt to initialize the end-to-end latency
to a value near the desired latency. This leads to underruns at startup because
the memblockq is initially empty and to very long adjustment times for long
latencies because the end-to-end latency at startup is significantly shorter
than the desired value.
This patch initializes the memblockq at startup and during source or sink changes
so that the end-to-end latency will be near the configured value. It also ensures
that there are no underruns if the source is slow to start and that the latency
does not grow too much when the sink is slow to start by adjusting the length of
the memblockq until the source has called push for the first time and the sink
has called pop for the second time. Waiting for the second pop is necessary
because the sink has not been started when the first pop is called.
For clarity, variables have been separated into input, output and main thread
variables.
A recent patch changed the MTU size from the default value of 48 to the value
returned by getsockopt(). This breaks HSP for some setups. To circumvent the
problem, this patch introduces a boolean parameter "autodetect_mtu" for
module-bluetooth-discover, module-bluez5-discover and module-bluez5-device to
make this use of getsockopt() configurable.
The RTSP client is not waiting anymore a new header after the
previous one (which can never occurs if RAOP is disconnected)
but after sending a command.
This patch fixes Issue #36.
https://github.com/hfujita/pulseaudio-raop2/issues/36
This patch is based on a similar idea as the previous one -- disabling
the flag right after the session is getting closed, rather than waiting
for a response from the server.
This patch fixes the issue #31.
https://github.com/hfujita/pulseaudio-raop2/issues/31
This patch sets c->is_recording = false when the RTSP FLUSH command
is issued. This avoids a race between the server response and
the record activation in some cases.
Regression introduced in commit 8c6407f:
raop: Merge TCP and UDP code paths + refactoring
Anyway, we need to determine if initial volume has to be setup before
sending RECORD or after:
- Setting it up *before* shouldn't be a problem: sink.c waits for
CONNECT state, set the volume and client.c triggers RECORD only once
he's got the SET_PARAMETER reply from server.
- Setting it up *after* seems to be more difficult if we try not to
send any audio before receiving the SET_PARAMETER reply form server. A
solution may be to send SET_PARAMETER just after the RECORD server
response is received and hope that it get processed by server during the
2sec latency/buffering time...
Attached patch implement that last solution. Works for me, but I cannot
guaranty it will with your hardware...
Some time one device announces multiple addresses (e.g. IPv4 one
and IPv6 one). Or some user may own multiple RAOP devices with
the same model name.
This patch adds device port to device description so that users
can distinguish appropriate RAOP sink by its address.
This patch switch the packet-buffer to use core memory pool instead of
manually allocating the room required for storing TCP/UDP packets. Packets
are now stored using pa_memchunk instead of internal struct. Quite a few
malloc saved compare to previous design.
ALAC encoding is to be prefered simply because ALAC audio packet reverse-
engineering and implementation is in better shape than raw PCM. Sending ALAC
audio does not mean compressing audio and thus linking an external library to
do so. ALAC packets has the ability to carry uncompressed PCM frames, and
that's what is implemented at the time.
TCP and UDP implementation are following two diffrent code path while code
logic is quite the same. This patch merges both code path into a unique one
and, thus, leads to a big refactoring. Major changes include:
- moving sink implementation to a separate file (raop-sink.c)
- move raop-sink.c protocol specific code to raop-client.c
- modernise RTSP session handling in TCP mode
- reduce code duplications between TCP and UDP modes
- introduce authentication support
- TCP mode does not constantly send silent audio anymore
About authentication: OPTIONS is now issued when the sink is preliminary
loaded. Client authentication appends at that time and credential is kept
for the whole sink lifetime. Later RTSP connection will thus look like this:
ANNOUNCE > 200 OK > SETUP > 200 OK > RECORD > 200 OK (no more OPTIONS). This
behaviour is similar to iTunes one.
Also this patch includes file name changes to match Pulseaudio naming
rules, as most of pulseaudio source code files seem to be using '-'
instead of '_' as a word separator.
RAOP authentication is using standard HTTP challenge-response authentication
scheme. This patch adds two helper functions that generate the proper hash
(for both techniques) given a username, a password and session related tokens.
MD5 hashing will be needed during the authentication process.
Original patch by Martin Blanchard. Patch splitted by
Hajime Fujita <crisp.fujita@nifty.com>.
Base64 implementation is now in a common file called raop_util.c.
Old Base64 files are removed but copyright is preserved.
Original patch by Martin Blanchard, patch splitted by
Hajime Fujita <crisp.fujita@nifty.com>.
When playback stops, a FLUSH command is send to the server and the sink
goes to IDLE. If playback resumes quickly, sink goes back to RUNNING
(without being SUSPENDED) and the sink should just start streaming again.
This patch implements this behaviour.
This patch adds an RTP audio packet retransmission support and a
circular buffer implementation for it.
This patch was originally written by Matthias Wabersich [1] and
later debugged and integrated into the latest tree by Hajime Fujita
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=42804#c44
During the discovery phase, raop servers send their capabilities
(supported encryption, audio codec...). These should be passed to the
raop sink via module's arguments.
Original patch written by Martin Blanchard, then modified by Hajime
Fujita <crisp.fujita@nifty.com> based on review comments by
Anton Lundin <glance@acc.umu.se>.
Now resolver_cb always dtrdup()s string blocks given by Avahi,
to make the code easier to maintain.
