Hi Thomas,
Thomas Martitz <kugel at rockbox.org> writes:
> I think this is a great project idea. I've been suffering from the
> problems you mentioned as well. However I think a lossless codec
> should be considered. Lossy codecs might not be acceptable for lots of
> people and a lossless codec might improve things sufficiently. But I
> can see a lossy codec being useful also for congested networks, so it
> could be an option.
When I did my research into codec choice around 9 months ago, I looked
into FLAC, along with lossless codecs like Vorbis. Off the top of my
head, I can't remember the details exactly, but my criteria were quite
straightforward: firstly, I wanted something to reduce my network
bandwidth requirements, since my 802.11g equiment wasn't hacking it[0];
secondly, I wanted something with low latency; thirdly, I wanted
something flexible, so that I could support different types of stream
and adjust intelligently but imperceptibly for different network
conditions; and lastly, I wanted something with low CPU and memory
requirements.
Opus performed favourably against all the lossy codecs I thought about
on pretty much all of these measures[1,2,3], but after discovering this,
I didn't really evaluate FLAC very much, since I believe FLAC and Vorbis
or AAC at high quality settings (eg, 320kbit/s) to be indistinguishable
under ABX testing, and since PulseAudio streaming, for me, is about
listening rather than archiving (for which you can use something far
less complex, and needn't be constrained by frame drops,
synchronisation, or real-time playback).
Of course, there are applications (such as audio manipulation) for which
one might want to have lossless transmission, and so I can see two
outcomes for my project. Potentially, I would have enough spare time to
implement FLAC support as well as Opus. But I don't want to over-commit
myself, and promise something I probably won't be able to achieve, since
I'm bound to concentrate on the more versatile Opus
implementation. Nonetheless, I would like the network code to be as
codec-agnostic as possible, and so would try and ensure that FLAC
support could be easily added at a later date.
[0] I have since upgraded to 802.11n equipment, but I still experience
degradations when I move far from my access point, or when streaming
more than 2-channel audio. I know I should get substantially more
throughput than the ~4.4 mbit/s required for 6-channel 16-bit 48kHz
PCM audio, but I don't, at least not reliably.
[1] http://opus-codec.org/comparison/
[2] https://tools.ietf.org/html/rfc6716#section-2.1.5
[3] https://tools.ietf.org/html/rfc6716#section-4.5
Regard,
Toby
