xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 3 years ago

#662 closed enhancement (wontfix)

Audio usability improvements

Reported by: onlyjob Owned by: onlyjob
Priority: minor Milestone: 2.0
Component: sound Version: 0.14.x
Keywords: Cc: rektide@…

Description

Please allow audio codec selection from menu (similar to video encodings).
Also please introduce per-codec audio buffering config options.
Also it will be useful to have audio codec priority order config option to change hardcoded CODEC_ORDER = [MP3, WAVPACK, WAV, FLAC, SPEEX].
Thanks.

Change History (6)

comment:1 Changed 5 years ago by Antoine Martin

Milestone: 1.0
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Please allow audio codec selection from menu (similar to video encodings).


The codecs are defined in the order that has been most tested, I fear that flac and speex are likely to not work very well out of the box, if at all. Exposing them via the gui would make it more likely that the user would end up with a non functional sound setup.

Also please introduce per-codec audio buffering config options.


Hmm could do. I would prefer if we chose the right buffering options for each encoding automatically, which might be do-able, just needs time spent testing all the platforms and network combinations. Of which there are many.
And since it works well enough with mp3 on most platforms, and that wavpack works well enough as a fallback... there is little incentive to work on this.

That said, you can play with:

XPRA_SOUND_QUEUE_TIME=450 xpra attach ...

And if you find a better value, re-assign to afarr for further testing and maybe we can tweak the defaults. Per-codec, and per-platform if needed.

The one thing that is in favour of this change is usage over very jittery connections, like 3G, but since we have statistical data on the connection latency we could take this into account to calculate an appropriate buffer delay / size automatically.

Note: the reason why the default buffer queue is so long is because on some platforms (OSX: #379), overruns and underruns are expensive to deal with.
Other related tickets: #362, #400


useful to have audio codec priority order config option to change hardcoded


To some extent, you can already affect this order by omitting some codecs from the speaker-codec and microphone-codec lists.

comment:2 Changed 4 years ago by rektide

Cc: rektide@… added

comment:3 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob
Status: assignednew

The codec order will honour the speaker-codec and microphone-codec options, trivial fix in r12849 (which I may backport).
It will still default to the pre-defined codec order if those command line / config file options are left unset. You can see these default values by running xpra _sound_query.


As for the buffering suggestion, that's unlikely to change because:

  • no-one has suggested a better value for the default initial buffer size
  • queue levels are now kept as low as possible: #849, this was possible thanks to the switch to gstreamer 1.x on OSX (#970) and win32 (#1041)
  • FYI, we now have many formats supported: #1090, #1212, #1204, ie:
    $ xpra attach --speaker-codec=help
    speaker codecs available: opus+gdp, opus+ogg, vorbis+gdp, vorbis+mka, \
        flac+gdp, flac+ogg, mp3, aac+gdp, aac+mpeg4, raw+gdp+lz4, raw+gdp+lzo, raw+gdp, \
        wav+lz4, wav+lzo, wav, wavpack, speex+gdp, speex+ogg
    

and unless proven otherwise, the defaults (vorbis or opus) are the best codecs for almost every possible use case - both in terms of quality, compression ratio and latency: #1074

comment:4 Changed 3 years ago by Antoine Martin

Milestone: 1.01.1

Milestone renamed

comment:5 Changed 3 years ago by Antoine Martin

Milestone: 1.12.0

Milestone renamed

comment:6 Changed 3 years ago by Antoine Martin

Resolution: wontfix
Status: newclosed

As per comment:3, closing.

Note: See TracTickets for help on using tickets.