On 07.12.19 18:49, Pali Rohár wrote:
On Saturday 07 December 2019 18:39:20 Georg Chini wrote:
Otherwise 44k1 could be chosen falsely here if
the headset
again sends both frequencies.
Remote side here send all supported frequencies. If there are more
frequencies we choose just one which we want to use and then send it to
remote side to inform which we have chosen. We must send exactly one
frequency to remote side.
But wasn't it the case, that if both frequencies are sent, 44k1 does not
work?
No, bug is different. Tested buggy headset supports both frequencies.
And if you negotiate 44.1kHz it works fine.
Bug is that headset returned in config buffer two frequences which is
invalid -- config buffer must contain only one frequency. Headset in
config buffer announce what is the final frequency used in audio stream
which is going to start transmitting. And by observation I figured out
that always when headset put both frequencies in config buffer it
starts transmitting audio stream at 48kHz.
Understood, so patch 6 looks good (apart from sometimes returning 0 in the
error case - but that's something general I already mentioned in the
previous
patch).
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
