PulseAudio 9.0 released | Hacker News Reader

PulseAudio 9.0 released

freedesktop.org

121 pointsronjouch20 comments

> PulseAudio has traditionally limited the maximum sample rate to 192 kHz, but it seems that there is some use for rates as high as 384 kHz, so the hard limit has been increased.

I can think of a use: plug a long wire into an audio out port and use it to transmit very-low-power AM radio without even needing a mixer. 384 kHz is enough to cover a decent chunk of the AM radio band :)

Of course, I bet your average "384 kHz" soundcard does some "direct stream digital" or similar garbage and has a truly atrocious SNR that those frequencies, so this might not actually work.

EDIT: Brain fart. 384 kilosamples per second is too low for normal AM radio unless there's a nonlinearity you can exploit. It would still be a fun experiment, though.

> but it seems that there is some use for rates as high as 384 kHz

Nyquist would suggest otherwise but why let pesky math get in the way of the golden ears. This is just more MHz war, DECT 6.0 style BS. I'm holding out for the dulcet tones of 1Mhz PCM audio myself.

In line with what others have mentioned, there are more uses for "sound" cards than just human ears. Maybe a musician wants to record some ultrasonic insect noise and slow it down to get a unique effect, or a scientist is working with non-human animals with ultrasonic hearing, or a digital restorer is using upper harmonics of noise on a recording to detect the original recording speed (https://en.m.wikipedia.org/wiki/The_Live_Wire:_Woody_Guthrie...).

Another note, since it's too late to edit: this part shows that the PulseAudio people may not know all that much about audio:

> The high rate is just an ALSA quirk originating from the choice of pretending that the compressed data is PCM audio with only two channels, while the compressed data actually carries more channels.

This is almost certainly not a quirk of ALSA, but more likely a reflection of how certain audio formats are (or were) transmitted over an AES or SPDIF digital link.

And why does PA need to have a 384k hard limit anyway? Just report the driver's supported rates, maybe with a blacklist for drivers like the old BT878(?) that support silly high sample rates (presumably for non-audio purposes).

I met a guy who needed to record bat sonar once.

It wouldn't surprise me if the hardware BOM cost of supporting these high sample rates for playback is basically zero. Any decent audio DAC will oversample internally, so if you don't actually care about fidelity at inaudibly high frequencies, you can just oversample to the same frequency but shove more bits in. Of course, if you do this, you ought to do your oversampling carefully to avoid sounding worse due to leading harmonics of your actual audible signal through your filters into your amp and tweeter.

If you use a bona fide 1-bit DAC, you can sample pretty much as fast as you want if all you care about is your pretty spec sheet. 2+MHz sampling? No problem!

The classic article is here:

https://xiph.org/~xiphmont/demo/neil-young.html

Count me out, of course, but I still think it would be amusing to find a "384 kHz" audio DAC that actually worked at high enough frequencies to transmit AM radio. You'd have to actively exploit insufficiently filtered harmonics to have a chance.

For audio purposes, maybe. Higher sample rates are really handy if you want to - for example - digitise an entire ham radio band at once and feed it to a software radio. (Some external hardware is required to down convert the sinal, such as a Softrock board, but it's quite cheap.)

Another thing I can think of, you can do some badass noise shaping at 384kHz.

I was impressed they switched to C11, since that's pretty cutting edge for a large C project.

This commit[1] however shows that what they're actually using is GNU11, i.e. C11 with GNU extensions, since they seem to rely on those. I double-checked the most recent revision of the configure.ac file[2] and it seems to be still at GNU11.

Not complaining, but I think the changelog entry ("Changed the C standard from C99 to C11") is ever so slightly misleading.

[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?i... [2] https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/conf...

Using 'true' C99 is a bad idea, because the headers of many libraries don't work if you use -std=c11.

gcc's default has always been the 'gnu' variant, so previously gnu90, now gnu99.

I has similar problems when I switched from the default (at the time) C++03 to -std=c++11 and found unexpected things broke. I switched to -std=gnu++11 and everything was fine.

I glanced at the surrounding commits and I couldn't see the motivation for the change. Do you know what pushed them to use C11 or GNU11?

Imagine wireless devices communicating with each other at frequencies higher than humanly audible? No, I don't mean radios. I mean some sort of "bot speak" that would allow for localized communication without an internet connection. Might be useful for researchers in the field without internet access. Could also be useful for business bots to host private conversations without adding to the chatter or needing access to private networks.

This idea has been developed [0].

Their idea was to use this to communicate data across an air gap.

[0] http://www.cnet.com/news/malware-jumps-air-gap-between-non-n...

Chromecast already does that for device pairing.

Indeed. The same person who worked on the Chromecast implementation has a repo with some other examples of sonic networking:

https://github.com/borismus/sonicnet.js

Why not radios? I don't see any obvious benefits in using sound waves over the RF spectrum.

The useful parts of the EM spectrum are crowded and regulated. Sound is anybody's game.

If I get this correctly, with a multi-microphone setup you can do similar background noise cancellation to what Amazon Echo does? Only it seems to remark that the audio source's position needs to be known before?

I think it's essentially half of what Echo does. Echo has to do two separate tasks [1]: The first is to figure out exactly what direction your voice is coming from. Once it has a direction, uses beamforming [2] to get a higher SNR for your voice. These two processes (probably) happen simultaneously.

The beamforming in Pulse Audio is simply the second half of this process. Given a microphone array and a desired direction to listen in, it can control the pickup pattern of the array by delaying the signals from each mic differently.

1: I haven't really studied how Echo works, so these are mostly assumptions. 2: https://en.wikipedia.org/wiki/Beamforming

I'm always eyeing the changelog to see if they finally got AirPlay 2 support merged

https://hfujita.github.io/pulseaudio-raop2/

Reply on news.ycombinator.com