> 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...).
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!
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.)
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.
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.
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.
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.
Readit News
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.
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.
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.
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...
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.
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...
https://github.com/borismus/sonicnet.js
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://hfujita.github.io/pulseaudio-raop2/
Deleted Comment