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. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
