Add RTP AC3 streaming support

[mincequi]

Hi,
I created this PR in order to support RTP streaming using an AC3 (aka Dolby Digital) encoder.
When using scream, i consider the network load too high (especially in WiFi environments). So, i wanted to use a compressed stream using AC3 at 256 kbps, which results in 1/6 of bandwidth and is also much more stable (less dropouts) than using raw PCM samples.

Unfortunately, i could not fully debug this change, because i could not make the project compile and install the driver. The streaming part is tested with a test app and should work. So, it would be great, if you could test it and give me feedback.

This is a preliminary version for this change. So, please let me know, if this is of interest and i will continue working on it.

Thanks a lot!

:)

[duncanthrax]

Thanks, I'll build it sometime tomorrow.

I had build RTP support in the past - it's in the "rtp" branch. Supports only PCM uncompressed stereo. The main problem with RTP is that receivers expect a continous stream, but Scream only sends data when an application plays audio. To fully support it, the Scream driver would need its own timer, which would be a major rework of the architecture.

So, a preliminary question: AC3 is fine, but do you really need RTP?

[mincequi]

Yes, i saw that you have a branch for RTP. This is where i took the RtpHeader from.
Is it defined in some RTP spec, that it has to be continuous? How do those clients behave, if the stream stops? My scream/rtp receiver (cornrow) just stops playing when the stream stops and continues when the stream sends again. Apple AirPlay (AirTunes) also uses this form of RTP streaming (with an additional RTSP session).
I decided to go for RTP because of some helpful additional information (like timestamp and sequence number) and i did not want to "invent" something for myself and stick to something that is "somehow" standard. RTP is strictly speaking not a protocol, but just some packetising and can easily be handled by (custom) receivers. So, having RTP would be great. Looking into the future we might also support SDP and SAP.

Unfortunately, i am not experienced with Visual Studio (building a windows driver) and i had several issues/questions:

1. How to commonly add additional include folders (for Media Foundation) for all targets?
2. How to link against it?
3. Can a windows driver actually link against media foundation?

Please also note, that my impl currently only supports 48 kHz, 16 bit, Stereo.

Thanks for testing.

[duncanthrax]

Concerning RTP: I think I tried mpv and vlc as RTP receivers, and both have algorithms that try to smoothe out jitter and packet loss. They add a lot of latency, and start to stutter when the stream stops and start. That is probably fine for playing continuous music, but for system sounds or games, it sucks.

Concerning driver development: In theory, you can compile whatever you like. But the code running in interrupt handlers and kernel workers is subject to numerous limitations. Linking in code written for userspace is likely to cause an instant bluescreen. Although a raw AC3 encoder might be OK if it does not need to do I/O.

[mincequi]

RTP: Ok, they shouldn't behave like this. They should respect the timestamp when to present the appropriate sample/frame. But on the other side: currently, for scream you need proprietary receivers anyway. So, why not go for proprietary receivers which handle RTP packets according to your needs?

I just updated some stuff regarding my PR: some fixes and i also committed a TestSender (written in Qt). Hope, that is of help. Please, tell me what you think. Thanks :)

[mincequi]

Hi,
i made another update. Could you find the time to test, whether this approach might be valid?
If ok, i can continue cleaning this up.

Btw, is it possible to add custom audio driver ui elements? (like setting bitrate, etc)

[jpmorrison]

cpiped https://github.com/b-fitzpatrick/cpiped does silence detection/buffering from an alsa input to a unix FIFO

combined with scream receiver, this worked really well for audio quality but I'm not sure about latency.
I was connecting the pipe to daapd and airplay speakers, but open source airplay seems to have a lot more buffering than iTunes.

a receiver/virtual sound card should handle the silence detection and synchronization.

Wishlist: SMPTE 2110 https://en.wikipedia.org/wiki/SMPTE_2110 and/or Dante/Audinate protocol. I don't know if there's a spec for Dante but could probably get a capture from a digital mixer or PA system.
PTP seems like a must have for pro quality AV.

[Arno500]

https://github.com/Haivision/srt
I think SRT should be also an option. This is a really solid protocol, but quite simple to implement and specifically made for low-latency and secure audio/video transmission.
Also hypothetically, Opus is a good protocol suited to low latency audio streaming (probably better than AC3, and it can attain better quality for same bitrate) and pretty simple to include too.