
PulseAudio 9.0 released - ronjouch
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/9.0/
======
amluto
> 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.

~~~
kevin_thibedeau
> 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.

~~~
nitrogen
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...](https://en.m.wikipedia.org/wiki/The_Live_Wire:_Woody_Guthrie_in_Performance_1949)).

~~~
nitrogen
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).

------
unwind
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...](https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=dcbe79bd630b6176eac7214834234218de744f2a)
[2]
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/conf...](https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/configure.ac)

~~~
CJefferson
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.

------
nercht12
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.

~~~
icebraining
Chromecast already does that for device pairing.

~~~
niftich
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](https://github.com/borismus/sonicnet.js)

------
lucb1e
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?

~~~
wrigby
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](https://en.wikipedia.org/wiki/Beamforming)

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

[https://hfujita.github.io/pulseaudio-
raop2/](https://hfujita.github.io/pulseaudio-raop2/)

