Re: sndio and bit perfect playback
pt., 14 paź 2022, 01:49 użytkownik Andre Smagin napisał: > On Thu, 13 Oct 2022 22:14:33 +0200 > Alexandre Ratchov wrote: > > > On Thu, Oct 13, 2022 at 03:11:50AM +, s...@skolma.com wrote: > > > in summary, audio works.. just not bit-perfectly :) > > > does anyone know if SNDIO supports such mode ? and how i might > configure it. > > > > bit-perfect is practical for one thing only: avoid questionings about > > whether the processing adds audible noise & distortion. I've tryed > > various hacks, including bypassing sndiod and neither was very > > practical. > > > > IMHO, the sndiod resampler covers 99% of the cases. To handle the > > remaining 1%, I just resample the files off-line. audio/sox is > > excellent for that. > > > > So, I'd suggest you to add "-e s24" to sndiod_flags and resample > > off-line when needed. > > > > HTH > > >>There is possibly one more use case for "bit-perfect". I agree, one more and not the only one. I have a small > >>collection of surround sound (5.1, 4.1, quad, etc) recordings extracted > >>from various DVDs, SACDs, and other sources. They are encoded in DTS > >>and Dolby Digital formats, as plain WAV files, and "compressed" to flac > >>format to prevent "smart" applications, such as ffmpeg, mpd, etc. from > >>trying to decode them and convert to stereo. > > >>My desktop is connected to a receiver via optical SPDIF cable. To get > >>the surround sound, I use mpd with 'device "snd/0"' option and Ario to > >>control the mpd daemon. mpd decodes the top layer (flac), but stops > >>there and sends DTS-wav to the sndiod without mangling it further. > >>However, if sndiod's sample rate does not match that of the recording, > i..t resamples the stream, which ruins the DTS and results in white noise. > > I made some test with my use case, and several cli players (siren, flac123, sox itself etc.). Using the USB Audioquest Dragonfly Red with led indicating actual sample rating. > >>I found out that I have to restart sndiod with either > >>'sndiod_flags="-m play -r 44100"' or 'sndiod_flags="-m play -r 48000"' > >>flags in /etc/rc.conf.local depending on the files I am playing, > >>and then it gets to the receiver without issues. > I have plenty of audio (stereo) files encoded with different bitrates and bit depths, mostly 24/96 for "hi-res" and 16/44.1 for ripped cds of my collection. I can confirm, that using above flags and restarting sndio it is possible to force DAC to work with its native supported modes (including bit depth) and succeed, with "proper" led colours too. There was one exception - setting 88200 is possible but no audible sound then. Not even using "native" 24/88,2 files. These files were only audible at 24/96 mode. Or default 48000 and 44100 set up by hand. > >>I have each music directory annotated with the sample rate used, like so: > > >>HAMLET: /storage $ ls music/dts/Pink\ Floyd/ > >>(1970) Atom Heart Mother (Quadrophonic Vinyl Conversion) (Dolby Digital > Quad 16-48) > >>(1973) Dark Side of the Moon (Alan Parson's Mix) (DVD-Audio) (DTS 4.1 > 24-48) > >>(1971) Echoes (Original 4.0 Quad Mix) (From Pink Floyd the Early Years > 1965-1972, Volume 5) (DTS Quad 16-48) > >>(1973) Dark Side of the Moon (Analogue Transfer From SACD) (DTS 5.1 > 16-44.1) > >>(1971) Meddle (From Pink Floyd the Early Years 1965-1972, Volume 5) (DTS > 5.1 16-48) > >>(1994) The Division Bell (2014, Warner Music Group, 20th Anniversary > Edition) (DTS 5.1 16-48) > >>Live: (1974) Live at Pompeii (DTS Quad 24-48) > > >>For '16-48' and '24-48' (bit depth-samplerate), I start sndiod with > >> sndiod_flags="-m play -r 48000" > >>for '16-44.1', I restart sndiod with > >>sndiod_flags="-m play -r 44100" > It seems to be sort of, say, "workaround" for "bit-perfect" audio "purists". While it is possible to detect encoding parameters of a particular file with e.g. soxi I can imagine script resetting sndiod flags and daemon itself for expected purposes. Even if it is possible (leave for a moment question about necesserity) it is not much "elegant". I was hoping (and tried) to use audioctl -f /dev/audioX rate=Z but no success / effect. > >>Bit depth does not seem to matter. I don't care about "bit-perfect", but > >>only about sending the dts stream to the receiver as-is, which works. > But it brings audioquest colours to proper shades, and I am affraid that is how it works in "consider-myself-to-be-the-audiophile" world, despite of fact if it is reasonable / non-audible. People choose "hi-res" files expecting better(?) audio quality and usually they get what they expect and belive to be truth. Even if it is not truth. Or not whole-truth. In my opinion telling: "it makes no sense at all, go resample or sox that stuff back to <> parameters, you won't hear the difference" is a bit simplifying. As much as "stereo is good enough for allmost everything", is it?. All in all it sounds like "go mess with volumio, or some pi-based-stuff, whatever, it is out of our scope". Seems
Re: sndio and bit perfect playback
On Sat, Jan 14, 2023 at 01:02:11AM +0100, Jan Stary wrote: > On Jan 13 15:58:20, euryd...@riseup.net wrote: > > On 23/01/13 12:42, Jan Stary wrote: > > > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > > > I was able to distinguish between samples created by > > > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > > > Carbon > > > > with HiFiMan Sundara headphones plugged in. To describe the > > > > circumstances + > > > > outcome briefly: 9 out of 10 correct in 10 trials > > > > > > http://stare.cz/.tmp/resample/ > > > Which is which? > > > > That's not how AB/X tests work, but it also doesn't matter because they're > > all > > the same file. > > Aaaah, now you have spoiled that as well :-) If only you'd added one byte of random metadata to each file to ensure that the hashes were different, this could have been so much more fun :-)
Re: sndio and bit perfect playback
On Jan 13 15:58:20, euryd...@riseup.net wrote: > On 23/01/13 12:42, Jan Stary wrote: > > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > > I was able to distinguish between samples created by > > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > > Carbon > > > with HiFiMan Sundara headphones plugged in. To describe the circumstances > > > + > > > outcome briefly: 9 out of 10 correct in 10 trials > > > > http://stare.cz/.tmp/resample/ > > Which is which? > > That's not how AB/X tests work, but it also doesn't matter because they're all > the same file. Aaaah, now you have spoiled that as well :-)
Re: sndio and bit perfect playback
On 23/01/13 12:42, Jan Stary wrote: > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > I was able to distinguish between samples created by > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > Carbon > > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > > outcome briefly: 9 out of 10 correct in 10 trials > > http://stare.cz/.tmp/resample/ > Which is which? That's not how AB/X tests work, but it also doesn't matter because they're all the same file. $ for num in $(seq -w 1 10); do ftp http://stare.cz/.tmp/resample/$num.wav > /dev/null 2>&1; done $ for num in $(seq -w 1 10); do sha256 ./$num.wav; done SHA256 (./01.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./02.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./03.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./04.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./05.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./06.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./07.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./08.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./09.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./10.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 https://en.wikipedia.org/wiki/ABX_test
Re: sndio and bit perfect playback
On Fri, Jan 13, 2023 at 01:10:56PM +0100, Jan Stary wrote: > > > > I'd certainly be interested in the ability to play audio in a way > > > > that avoids resampling altogether, > > > > > > If you have a 48kHz file, and your audio device can only do 44100, > > > then you have to resample, no way around it. > > > > > similar to what a user can do on FreeBSD with the > > > > following sysctl tweaks: > > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > > > if the sample rate (or some other characteristics) is not what the device > > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 > > On Jan 10 09:36:28, a...@caoua.org wrote: > > chown /dev/audio* > > rcctl stop sndiod > > After doing that, > > $ play -V 48000.wav > play:SoX v14.4.2 > play INFO formats: detected file format type `wav' > > Input File : '48000.wav' > Channels : 2 > Sample Rate: 48000 > Precision : 16-bit > Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors > File Size : 4.80M > Bit Rate : 1.54M > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > > Output File: 'default' (sndio) > Channels : 2 > Sample Rate: 48000 > Precision : 16-bit > Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > play INFO sox: effects chain: input 48000Hz 2 channels > play INFO sox: effects chain: output 48000Hz 2 channels > In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [---=|=--- ] > Clip:0 > > $ play -V 44100.wav > play:SoX v14.4.2 > play INFO formats: detected file format type `wav' > > Input File : '44100.wav' > Channels : 2 > Sample Rate: 44100 > Precision : 16-bit > Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors > File Size : 4.41M > Bit Rate : 1.41M > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > Output File: 'default' (sndio) > Channels : 2 > Sample Rate: 44100 > Precision : 16-bit > Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > play INFO sox: effects chain: input 44100Hz 2 channels > play INFO sox: effects chain: output 44100Hz 2 channels > In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ] Clip:0 > Aborted. > > $ aucat -i 44100.wav > default: unsupported audio params > > $ aucat -i 48000.wav > default: unsupported audio params > > > It seems sox negotiates either 48000 or 44100 with sndio > (meaning the sndio library, not the non-running sndiod) and sends that, > but aucat errors out. But the device itself can do 48000 (says audioctl), > so is that a bug in aucat? > It's not related to the sample rate. Internally aucat uses 24-bit samples lsb-aligned in 32-bit words. Then, it assumes the device supports everything and doesn't bother setting up a conversion layer.
Re: sndio and bit perfect playback
> > > I'd certainly be interested in the ability to play audio in a way > > > that avoids resampling altogether, > > > > If you have a 48kHz file, and your audio device can only do 44100, > > then you have to resample, no way around it. > > > similar to what a user can do on FreeBSD with the > > > following sysctl tweaks: > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > > if the sample rate (or some other characteristics) is not what the device > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 On Jan 10 09:36:28, a...@caoua.org wrote: > chown /dev/audio* > rcctl stop sndiod After doing that, $ play -V 48000.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '48000.wav' Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors File Size : 4.80M Bit Rate : 1.54M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input48000Hz 2 channels play INFO sox: effects chain: output 48000Hz 2 channels In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [ ---=|=--- ]Clip:0 $ play -V 44100.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '44100.wav' Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors File Size : 4.41M Bit Rate : 1.41M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input44100Hz 2 channels play INFO sox: effects chain: output 44100Hz 2 channels In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ]Clip:0 Aborted. $ aucat -i 44100.wav default: unsupported audio params $ aucat -i 48000.wav default: unsupported audio params It seems sox negotiates either 48000 or 44100 with sndio (meaning the sndio library, not the non-running sndiod) and sends that, but aucat errors out. But the device itself can do 48000 (says audioctl), so is that a bug in aucat? Jan
Re: sndio and bit perfect playback
On Jan 09 13:10:09, euryd...@riseup.net wrote: > I was able to distinguish between samples created by > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > outcome briefly: 9 out of 10 correct in 10 trials http://stare.cz/.tmp/resample/ Which is which?
Re: sndio and bit perfect playback
On Wed, Jan 11, 2023 at 02:43:25PM +0100, Jan Stary wrote: > On Jan 11 01:10:11, a...@caoua.org wrote: > > On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote: > > > > > > > > # If I recall correctly, I converted to FLAC here because the WAV > > > > > headers > > > > > # generated by aucat and SoX differed, and so SoX would refuse to > > > > > play WAV fil > > > > es > > > > > # created by aucat. > > > > > > > > That would be a bug in itself. > > > > How exactly does SoX refuse to play the WAVs created by aucat? > > > > > > sox is strict about headers and will complain if cbSize is inconsistent > > > with > > > fmt size. Workaround is to use the '-t sndfile' option. > > > > > > aucat is not alone here; several other programs write .wav files that > > > require this option with sox. > > > > > > > Here's a diff to switch aucat to extended wav format. According to > > Microsoft docs, it is needed if bits > 16 or if there are more than 2 > > channels, which aucat supports. It fixes the sox problem. > > Thank you. > > One nit that's perhaps related: $ aucat -n in.wav -o out.wav > produces a stereo 24bit out.wav, as -c 0:1 -e s24 is the default. > Would it make more sense with -n to preserve the characteristics > of in.wav instead? > Yes, this is on my todo list, including preserving the sample rate, which is the most annoying.
Re: sndio and bit perfect playback
On Jan 11 01:10:11, a...@caoua.org wrote: > On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote: > > > > > > # If I recall correctly, I converted to FLAC here because the WAV > > > > headers > > > > # generated by aucat and SoX differed, and so SoX would refuse to play > > > > WAV fil > > > es > > > > # created by aucat. > > > > > > That would be a bug in itself. > > > How exactly does SoX refuse to play the WAVs created by aucat? > > > > sox is strict about headers and will complain if cbSize is inconsistent with > > fmt size. Workaround is to use the '-t sndfile' option. > > > > aucat is not alone here; several other programs write .wav files that > > require this option with sox. > > > > Here's a diff to switch aucat to extended wav format. According to > Microsoft docs, it is needed if bits > 16 or if there are more than 2 > channels, which aucat supports. It fixes the sox problem. Thank you. One nit that's perhaps related: $ aucat -n in.wav -o out.wav produces a stereo 24bit out.wav, as -c 0:1 -e s24 is the default. Would it make more sense with -n to preserve the characteristics of in.wav instead? Jan > No regressions found with various ports and few windows programs. > > ok? > > Index: afile.c > === > RCS file: /cvs/src/usr.bin/aucat/afile.c,v > retrieving revision 1.9 > diff -u -p -u -p -r1.9 afile.c > --- afile.c 24 Oct 2021 21:24:15 - 1.9 > +++ afile.c 10 Jan 2023 23:52:47 - > @@ -432,12 +432,17 @@ afile_wav_writehdr(struct afile *f) > le32_set(&hdr.riff.size, f->endpos - sizeof(hdr.riff)); > memcpy(hdr.fmt_hdr.id, wav_id_fmt, 4); > le32_set(&hdr.fmt_hdr.size, sizeof(hdr.fmt)); > - le16_set(&hdr.fmt.fmt, 1); > + le16_set(&hdr.fmt.fmt, WAV_FMT_EXT); > le16_set(&hdr.fmt.nch, f->nch); > le32_set(&hdr.fmt.rate, f->rate); > le32_set(&hdr.fmt.byterate, f->rate * f->par.bps * f->nch); > le16_set(&hdr.fmt.blkalign, f->par.bps * f->nch); > le16_set(&hdr.fmt.bits, f->par.bits); > + le16_set(&hdr.fmt.extsize, > + WAV_FMT_EXT_SIZE - WAV_FMT_SIZE - sizeof(hdr.fmt.extsize)); > + le16_set(&hdr.fmt.valbits, f->par.bits); > + le16_set(&hdr.fmt.extfmt, 1); > + memcpy(&hdr.fmt.guid, wav_guid, sizeof(hdr.fmt.guid)); > memcpy(hdr.data_hdr.id, wav_id_data, 4); > le32_set(&hdr.data_hdr.size, f->endpos - f->startpos); > return afile_writehdr(f, &hdr, sizeof(struct wav_hdr)); > >
Re: sndio and bit perfect playback
On Tue, Jan 10, 2023 at 08:22:27PM +, John Rigg wrote: > > > > # If I recall correctly, I converted to FLAC here because the WAV headers > > > # generated by aucat and SoX differed, and so SoX would refuse to play > > > WAV fil > > es > > > # created by aucat. > > > > That would be a bug in itself. > > How exactly does SoX refuse to play the WAVs created by aucat? > > sox is strict about headers and will complain if cbSize is inconsistent with > fmt size. Workaround is to use the '-t sndfile' option. > > aucat is not alone here; several other programs write .wav files that > require this option with sox. > Here's a diff to switch aucat to extended wav format. According to Microsoft docs, it is needed if bits > 16 or if there are more than 2 channels, which aucat supports. It fixes the sox problem. No regressions found with various ports and few windows programs. ok? Index: afile.c === RCS file: /cvs/src/usr.bin/aucat/afile.c,v retrieving revision 1.9 diff -u -p -u -p -r1.9 afile.c --- afile.c 24 Oct 2021 21:24:15 - 1.9 +++ afile.c 10 Jan 2023 23:52:47 - @@ -432,12 +432,17 @@ afile_wav_writehdr(struct afile *f) le32_set(&hdr.riff.size, f->endpos - sizeof(hdr.riff)); memcpy(hdr.fmt_hdr.id, wav_id_fmt, 4); le32_set(&hdr.fmt_hdr.size, sizeof(hdr.fmt)); - le16_set(&hdr.fmt.fmt, 1); + le16_set(&hdr.fmt.fmt, WAV_FMT_EXT); le16_set(&hdr.fmt.nch, f->nch); le32_set(&hdr.fmt.rate, f->rate); le32_set(&hdr.fmt.byterate, f->rate * f->par.bps * f->nch); le16_set(&hdr.fmt.blkalign, f->par.bps * f->nch); le16_set(&hdr.fmt.bits, f->par.bits); + le16_set(&hdr.fmt.extsize, + WAV_FMT_EXT_SIZE - WAV_FMT_SIZE - sizeof(hdr.fmt.extsize)); + le16_set(&hdr.fmt.valbits, f->par.bits); + le16_set(&hdr.fmt.extfmt, 1); + memcpy(&hdr.fmt.guid, wav_guid, sizeof(hdr.fmt.guid)); memcpy(hdr.data_hdr.id, wav_id_data, 4); le32_set(&hdr.data_hdr.size, f->endpos - f->startpos); return afile_writehdr(f, &hdr, sizeof(struct wav_hdr));
Re: sndio and bit perfect playback
On 23/01/10 09:36, Alexandre Ratchov wrote:
> On Mon, Jan 09, 2023 at 01:10:09PM -0700, Ashlen wrote:
> >
> > Although I need to finalize the Perl script I was using to do this (life
> > gets
> > busy), in practice I was able to distinguish between samples created by
> > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1
> > Carbon
> > with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> > outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> > array containing the givens A and B to get an unknown X; comparing 15
> > seconds of
> > audio; audio/sox as the playback software. In the future, I would do >=16
> > trials, and perhaps conduct the tests from my desktop instead since it has a
> > discrete amp and DAC.
> >
> > In offline resampling from 48kHz to 44.1kHz, the highs were most affected
> > and
> > that's what I was able to use to distinguish between samples. The
> > percussion,
> > especially the cymbals, sounded different in particular because the clip
> > resampled by aucat had cymbal crashes that seemed to 'shimmer' much less
> > (the
> > decay was more rapid). The spectrograms seemed to confirm that the highs
> > were
> > most affected.
> >
> > Whether that means "low quality resampling" or merely that the results of
> > the
> > two commands can be differentiated is something I'm uncertain of. Either
> > way, I
> > don't know enough about C or sndio internals to be useful in that domain
> > yet. As
> > an aside, I did find this to be a useful resource for learning about digital
> > audio resampling, and they recommend audio/sox there.
> >
> > https://ccrma.stanford.edu/~jos/resample/
> >
> > I hadn't said anything about this earlier because I wanted to take the time
> > to
> > finish + document the script, reproduce my results with a royalty free
> > sample at
> > a greater trial count, and then post. Given that I haven't done so yet, I
> > can at
> > least post the commands used to resample the audio for those that are
> > interested.
> >
> >
> > # This was originally an opus file downloaded with www/yt-dlp.
> > # Converting to WAV so both SoX and aucat can work with it.
> > $ opusdec input.{opus,wav}
> >
> > # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> > #
> > # If I recall correctly, I converted to FLAC here because the WAV headers
> > # generated by aucat and SoX differed, and so SoX would refuse to play WAV
> > files
> > # created by aucat.
> > $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> > $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o
> > output-aucat.flac
> >
> > # Generate spectrograms for later inspection/comparison.
> > $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> > $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
> >
>
> Thank you for all the details. Do you mind sharing the youtube link
> (or the input.wav file) so I can experiment with the same file and
> examine the data
I don't mind. :) I provided the way I downloaded it in the last reply, although
I'll add the link here as well for convenience.
https://www.youtube.com/watch?v=ei8hPkyJ0bU
> > I'd certainly be interested in the ability to play audio in a way that
> > avoids
> > resampling altogether, similar to what a user can do on FreeBSD with the
> > following sysctl tweaks:
> >
> > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
> >
>
> This is equivalent to bypassing sndiod. The OpenBSD equivalent is as
> follows:
>
> chown /dev/audio*
> rcctl stop sndiod
Interesting, I'll try that later to see how it works. I suppose this does give
up the advantage of a privilege separated audio daemon, however, and the
ownership modification means that a regular user can change things they
otherwise couldn't [ mixerctl(8), audioctl(8) ]. Hard to have that cake and eat
it too. Though it does leave me feeling impressed with the way OpenBSD's sound
infrastructure is designed. Lots of other systems would ship with a regular user
having raw access to the device itself, and it's a plus in my book that OpenBSD
doesn't (instead it's _sndiop).
> Note that bit-perfect audio and avoiding resampling are not the same
> thing. The latter is more complicated but it would keep current
> features working (mixing, routing, device switching) by making sndiod
> dynamically set device sample rates to match the sample rate of a
> particular client (for instance an audio player), other programs (if
> any) would resample.
This would be a very cool thing to have, and this improvement actually has the
opportunity to keep the ownership of `/dev/audio*` intact as well. Though I
guess sndiod(8) would also have to keep track of what rates the device is
capable of while it does this, so that whenever a client declares a rate that
doesn't match the device's capabilities it would resample instead of trying and
failing to dynamically set the device's sample rat
Re: sndio and bit perfect playback
On 23/01/09 22:16, Jan Stary wrote:
> On Jan 09 13:10:09, euryd...@riseup.net wrote:
> >
> > Although I need to finalize the Perl script I was using to do this (life
> > gets
> > busy), in practice I was able to distinguish between samples created by
> > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1
> > Carbon
> > with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> > outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> > array containing the givens A and B to get an unknown X; comparing 15
> > seconds of
> > audio; audio/sox as the playback software. In the future, I would do >=16
> > trials, and perhaps conduct the tests from my desktop instead since it has a
> > discrete amp and DAC.
> >
> > In offline resampling from 48kHz to 44.1kHz, the highs were most affected
> > and
> > that's what I was able to use to distinguish between samples. The
> > percussion,
> > especially the cymbals, sounded different in particular because the clip
> > resampled by aucat had cymbal crashes that seemed to 'shimmer' much less
> > (the
> > decay was more rapid). The spectrograms seemed to confirm that the highs
> > were
> > most affected.
> >
> > Whether that means "low quality resampling" or merely that the results of
> > the
> > two commands can be differentiated is something I'm uncertain of. Either
> > way, I
> > don't know enough about C or sndio internals to be useful in that domain
> > yet. As
> > an aside, I did find this to be a useful resource for learning about digital
> > audio resampling, and they recommend audio/sox there.
> >
> > https://ccrma.stanford.edu/~jos/resample/
> >
> > I hadn't said anything about this earlier because I wanted to take the time
> > to
> > finish + document the script, reproduce my results with a royalty free
> > sample at
> > a greater trial count, and then post. Given that I haven't done so yet, I
> > can at
> > least post the commands used to resample the audio for those that are
> > interested.
> >
> >
> > # This was originally an opus file downloaded with www/yt-dlp.
> > # Converting to WAV so both SoX and aucat can work with it.
> > $ opusdec input.{opus,wav}
>
> Can you please point to the specific opus file,
> so that I can reproduce exactly what you have done?
Sure. It was the first fifteen seconds in particular I compared against. The
song is a guilty pleasure from my adolescent years that I felt like indulging
that day, though, so please don't judge too much. :p Anyway, I used '--simulate'
here, but of course you'd remove it to actually download the file. Note the
format number if it feels important to check what exactly is being downloaded.
$ yt-dlp -xf bestaudio/best --simulate
'https://www.youtube.com/watch?v=ei8hPkyJ0bU'
[youtube] ei8hPkyJ0bU: Downloading webpage
[youtube] ei8hPkyJ0bU: Downloading android player API JSON
[SponsorBlock] Fetching SponsorBlock segments
[SponsorBlock] Found 1 segments in the SponsorBlock database
[info] ei8hPkyJ0bU: Downloading 1 format(s): 251
In case you're interested in my ~/.config/yt-dlp/config contents as well:
$ cat ~/.config/yt-dlp/config
--audio-quality 0
--embed-metadata
--embed-subs
--embed-thumbnail
--format 'bestvideo*[height<=?1080][width<=?1920]+bestaudio/best'
--output "${HOME}/Downloads/%(uploader)s/%(title)s.%(ext)s"
--sponsorblock-mark default
--sub-langs en,en-orig,-live_chat
--write-description
--write-info-json
> > # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> > #
> > # If I recall correctly, I converted to FLAC here because the WAV headers
> > # generated by aucat and SoX differed, and so SoX would refuse to play WAV
> > files
> > # created by aucat.
>
> That would be a bug in itself.
> How exactly does SoX refuse to play the WAVs created by aucat?
Unsure what the error itself means, but I'll share it. Also, I forgot to add
`-n` to aucat(1) in my previous mail, which is necessary to resample the file
without playback. Oops.
$ aucat -n -i input.wav -h wav -r 44100 -e s16 -o output.wav
$ play output.wav
play FAIL formats: can't open input file `output.wav': WAVE header error:
cbSize inconsistent with fmt size
> > $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> > $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o
> > output-aucat.flac
>
> sox dithers by default; can you try with sox -D
> to see of the results are more similar?
I'll add testing against a sample with `sox -D` to my TODOs. Life's been getting
pretty busy, sadly. :( But I'd be happy to test when I get the time. Would be
good to drop `-G` from the sox invocation now that I think about it. I do
usually use it when resampling things offline, but it's an unneeded additional
variable that could make isolating things in testing more difficult.
> > # Generate spectrograms for later inspection/comparison.
> > $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> > $ sox output-aucat
Re: sndio and bit perfect playback
> > # If I recall correctly, I converted to FLAC here because the WAV headers > > # generated by aucat and SoX differed, and so SoX would refuse to play WAV > > fil > es > > # created by aucat. > > That would be a bug in itself. > How exactly does SoX refuse to play the WAVs created by aucat? sox is strict about headers and will complain if cbSize is inconsistent with fmt size. Workaround is to use the '-t sndfile' option. aucat is not alone here; several other programs write .wav files that require this option with sox.
Re: sndio and bit perfect playback
Geoff Steckel wrote: > Other OSes allow unprivileged users to access raw audio devices > and bypass any system processing. > Users should be given that option. But they are given that option; they can run other systems. Other OSes allow unprivileged users to run telnetd and bypass modern security practices. Users should be given that option. No, sometimes people don't get everything! We are building a curated experience, not a comprehensive everything-you-could possibly want environment. There are numerous reasons for that. Please stop it with the expansive rhetoric which is indistinguishable for a demand for additional maintance.
Re: sndio and bit perfect playback
Signal processing which modifies the data stream -must- (almost) always dither. Without that it introduces -significant and audible- distortion. That has been standard practice in digital audio for more than 50 years. That is why sox dithers by default. Dithering is also known as noise shaping. Its purpose is to make the distortion introduced by signal processing as inaudible as possible. The distortion -cannot- be removed but it can be changed to broadband noise which is much less objectionable. OpenBSD is known for good engineering practice. Since the audio system is set to -force- users to accept whatever signal processing the system applies that processing should follow good practice as well. Other OSes allow unprivileged users to access raw audio devices and bypass any system processing. Users should be given that option. Geoff Steckel On 1/10/23 03:11, Jan Stary wrote: I don't get the point of your message explaning what dither is. My whole point was that one of the sources of the perceived difference between how sox resamples and hows aucat resamples might be dithering, as aucat does not differ (right?).
Re: sndio and bit perfect playback
On Tue, Jan 10, 2023 at 09:11:13AM +0100, Jan Stary wrote: > I don't get the point of your message explaning what dither is. > My whole point was that one of the sources of the perceived > difference between how sox resamples and hows aucat resamples > might be dithering, as aucat does not differ (right?). > You're right, aucat doesn't dither and quantization noise is audible for quiet inputs (including when resampling is not involved at all).
Re: sndio and bit perfect playback
On Mon, Jan 09, 2023 at 01:10:09PM -0700, Ashlen wrote:
>
> Although I need to finalize the Perl script I was using to do this (life gets
> busy), in practice I was able to distinguish between samples created by
> audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
> with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> array containing the givens A and B to get an unknown X; comparing 15 seconds
> of
> audio; audio/sox as the playback software. In the future, I would do >=16
> trials, and perhaps conduct the tests from my desktop instead since it has a
> discrete amp and DAC.
>
> In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
> that's what I was able to use to distinguish between samples. The percussion,
> especially the cymbals, sounded different in particular because the clip
> resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
> decay was more rapid). The spectrograms seemed to confirm that the highs were
> most affected.
>
> Whether that means "low quality resampling" or merely that the results of the
> two commands can be differentiated is something I'm uncertain of. Either way,
> I
> don't know enough about C or sndio internals to be useful in that domain yet.
> As
> an aside, I did find this to be a useful resource for learning about digital
> audio resampling, and they recommend audio/sox there.
>
> https://ccrma.stanford.edu/~jos/resample/
>
> I hadn't said anything about this earlier because I wanted to take the time to
> finish + document the script, reproduce my results with a royalty free sample
> at
> a greater trial count, and then post. Given that I haven't done so yet, I can
> at
> least post the commands used to resample the audio for those that are
> interested.
>
>
> # This was originally an opus file downloaded with www/yt-dlp.
> # Converting to WAV so both SoX and aucat can work with it.
> $ opusdec input.{opus,wav}
>
> # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> #
> # If I recall correctly, I converted to FLAC here because the WAV headers
> # generated by aucat and SoX differed, and so SoX would refuse to play WAV
> files
> # created by aucat.
> $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac
>
> # Generate spectrograms for later inspection/comparison.
> $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
>
Thank you for all the details. Do you mind sharing the youtube link
(or the input.wav file) so I can experiment with the same file and
examine the data
>
> I'd certainly be interested in the ability to play audio in a way that avoids
> resampling altogether, similar to what a user can do on FreeBSD with the
> following sysctl tweaks:
>
> # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
>
This is equivalent to bypassing sndiod. The OpenBSD equivalent is as
follows:
chown /dev/audio*
rcctl stop sndiod
Note that bit-perfect audio and avoiding resampling are not the same
thing. The latter is more complicated but it would keep current
features working (mixing, routing, device switching) by making sndiod
dynamically set device sample rates to match the sample rate of a
particular client (for instance an audio player), other programs (if
any) would resample.
Re: sndio and bit perfect playback
I don't get the point of your message explaning what dither is. My whole point was that one of the sources of the perceived difference between how sox resamples and hows aucat resamples might be dithering, as aucat does not differ (right?). On Jan 09 17:01:52, g...@oat.com wrote: > The math goes back to Shannon and sampling theory: > > Any time you remove significant digits you remove information. > One interpretation is that you introduce noise. > Period. The math says so. > The math says what the resulting power is. > > You have the option to determine where the noise goes. > > If you do nothing the noise is correlated with the input > signal. You get what in audio terms is intermodulation > distortion. In the simplest case this is harmonic distortion. > > You can spread the noise by applying digital transforms. > You -cannot- remove it entirely. > The easiest and most common method is dithering > which spreads the power over the (audio) spectrum. > That result can be white, pink etc. > > People are very sensitive to intermodulation distortion. > Less sensitive to harmonic distortion. > (People who like vacuum tubes and vinyl -like- > second harmonic distortion = "rich sound" ) > Very less sensitive to random noise. > Even less to mostly-random noise outside of 1KHz-5KHz or so. > > Some of the standard minimal tests of audio equipment translated > to the digital domain: > > Run FFTs with sufficient accuracy on the following > (double precision at least for good results): > (a) a precise sine wave (32 bits or better) truncated to 24 and 16 bits > testing harmonic distortion (usually 1KHz) > > (b) two sines (usually 1KHz and 7KHz) testing intermodulation distortion > > (c) (a) and (b) resampled (96 to 48, 48 to 44.1, etc.) and > resampled 24 to 16 testing purely digital distortion > > Decide for yourself if the results are significant for your use. > > If you read the sox(1) man page you'll notice that it computes > in 32 bits and applies dithering -by default- when truncating to > the output sample width. You can defeat it if you want and > wish to accept the result. > >
Re: sndio and bit perfect playback
The math goes back to Shannon and sampling theory: Any time you remove significant digits you remove information. One interpretation is that you introduce noise. Period. The math says so. The math says what the resulting power is. You have the option to determine where the noise goes. If you do nothing the noise is correlated with the input signal. You get what in audio terms is intermodulation distortion. In the simplest case this is harmonic distortion. You can spread the noise by applying digital transforms. You -cannot- remove it entirely. The easiest and most common method is dithering which spreads the power over the (audio) spectrum. That result can be white, pink etc. People are very sensitive to intermodulation distortion. Less sensitive to harmonic distortion. (People who like vacuum tubes and vinyl -like- second harmonic distortion = "rich sound" ) Very less sensitive to random noise. Even less to mostly-random noise outside of 1KHz-5KHz or so. Some of the standard minimal tests of audio equipment translated to the digital domain: Run FFTs with sufficient accuracy on the following (double precision at least for good results): (a) a precise sine wave (32 bits or better) truncated to 24 and 16 bits testing harmonic distortion (usually 1KHz) (b) two sines (usually 1KHz and 7KHz) testing intermodulation distortion (c) (a) and (b) resampled (96 to 48, 48 to 44.1, etc.) and resampled 24 to 16 testing purely digital distortion Decide for yourself if the results are significant for your use. If you read the sox(1) man page you'll notice that it computes in 32 bits and applies dithering -by default- when truncating to the output sample width. You can defeat it if you want and wish to accept the result.
Re: sndio and bit perfect playback
On Jan 09 13:10:09, euryd...@riseup.net wrote:
> > > aucat(1) currently says
> > >
> > > BUGS
> > >Resampling is low quality.
> > >
> > > Is this still considered to be the case?
> >
> > IMO, it doesn't deserve the BUGS section anymore, I'll remove this
> > sentence. Objections?
>
> Although I need to finalize the Perl script I was using to do this (life gets
> busy), in practice I was able to distinguish between samples created by
> audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
> with HiFiMan Sundara headphones plugged in. To describe the circumstances +
> outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
> array containing the givens A and B to get an unknown X; comparing 15 seconds
> of
> audio; audio/sox as the playback software. In the future, I would do >=16
> trials, and perhaps conduct the tests from my desktop instead since it has a
> discrete amp and DAC.
>
> In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
> that's what I was able to use to distinguish between samples. The percussion,
> especially the cymbals, sounded different in particular because the clip
> resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
> decay was more rapid). The spectrograms seemed to confirm that the highs were
> most affected.
>
> Whether that means "low quality resampling" or merely that the results of the
> two commands can be differentiated is something I'm uncertain of. Either way,
> I
> don't know enough about C or sndio internals to be useful in that domain yet.
> As
> an aside, I did find this to be a useful resource for learning about digital
> audio resampling, and they recommend audio/sox there.
>
> https://ccrma.stanford.edu/~jos/resample/
>
> I hadn't said anything about this earlier because I wanted to take the time to
> finish + document the script, reproduce my results with a royalty free sample
> at
> a greater trial count, and then post. Given that I haven't done so yet, I can
> at
> least post the commands used to resample the audio for those that are
> interested.
>
>
> # This was originally an opus file downloaded with www/yt-dlp.
> # Converting to WAV so both SoX and aucat can work with it.
> $ opusdec input.{opus,wav}
Can you please point to the specific opus file,
so that I can reproduce exactly what you have done?
> # Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
> #
> # If I recall correctly, I converted to FLAC here because the WAV headers
> # generated by aucat and SoX differed, and so SoX would refuse to play WAV
> files
> # created by aucat.
That would be a bug in itself.
How exactly does SoX refuse to play the WAVs created by aucat?
> $ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
> $ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac
sox dithers by default; can you try with sox -D
to see of the results are more similar?
> # Generate spectrograms for later inspection/comparison.
> $ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
> $ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
>
> I'd certainly be interested in the ability to play audio in a way
> that avoids resampling altogether,
If you have a 48kHz file, and your audio device can only do 44100,
then you have to resample, no way around it.
> similar to what a user can do on FreeBSD with the
> following sysctl tweaks:
>
> # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
>
> https://www.freebsd.org/cgi/man.cgi?query=sound&manpath=FreeBSD+13.1-RELEASE&format=html
It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do
if the sample rate (or some other characteristics) is not what the device
itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10
Re: sndio and bit perfect playback
On 23/01/09 06:22, Alexandre Ratchov wrote:
> On Sun, Jan 08, 2023 at 10:56:31PM +0100, Jan Stary wrote:
> > On Oct 16 08:18:17, a...@caoua.org wrote:
> > > On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote:
> > > > On 10/14/22 11:21, Alexandre Ratchov wrote:
> > > > > Here are the measures of the aliasing noise using sine sweeps. Check
> > > > > the figure for the 44.1kHz to 48kH conversion, the sndiod column:
> > > > >
> > > > > https://arverb.com/pub/src/
> >
> >
> > aucat(1) currently says
> >
> > BUGS
> > Resampling is low quality.
> >
> > Is this still considered to be the case?
> >
>
> IMO, it doesn't deserve the BUGS section anymore, I'll remove this
> sentence. Objections?
Not necessarily an objection, but I've been watching this thread silently since
it started and wanted to voice some of my thoughts.
Although I need to finalize the Perl script I was using to do this (life gets
busy), in practice I was able to distinguish between samples created by
audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon
with HiFiMan Sundara headphones plugged in. To describe the circumstances +
outcome briefly: 9 out of 10 correct in 10 trials; randomly sampling from an
array containing the givens A and B to get an unknown X; comparing 15 seconds of
audio; audio/sox as the playback software. In the future, I would do >=16
trials, and perhaps conduct the tests from my desktop instead since it has a
discrete amp and DAC.
In offline resampling from 48kHz to 44.1kHz, the highs were most affected and
that's what I was able to use to distinguish between samples. The percussion,
especially the cymbals, sounded different in particular because the clip
resampled by aucat had cymbal crashes that seemed to 'shimmer' much less (the
decay was more rapid). The spectrograms seemed to confirm that the highs were
most affected.
Whether that means "low quality resampling" or merely that the results of the
two commands can be differentiated is something I'm uncertain of. Either way, I
don't know enough about C or sndio internals to be useful in that domain yet. As
an aside, I did find this to be a useful resource for learning about digital
audio resampling, and they recommend audio/sox there.
https://ccrma.stanford.edu/~jos/resample/
I hadn't said anything about this earlier because I wanted to take the time to
finish + document the script, reproduce my results with a royalty free sample at
a greater trial count, and then post. Given that I haven't done so yet, I can at
least post the commands used to resample the audio for those that are
interested.
# This was originally an opus file downloaded with www/yt-dlp.
# Converting to WAV so both SoX and aucat can work with it.
$ opusdec input.{opus,wav}
# Resample 16-bit 48kHz WAV file to 44.1kHz using both SoX and aucat(1).
#
# If I recall correctly, I converted to FLAC here because the WAV headers
# generated by aucat and SoX differed, and so SoX would refuse to play WAV files
# created by aucat.
$ sox -G input.wav -t wav - rate -v 44100 | flac - -o output-sox.flac
$ aucat -i input.wav -h wav -r 44100 -e s16 -o - | flac - -o output-aucat.flac
# Generate spectrograms for later inspection/comparison.
$ sox output-sox.flac -n spectrogram -o spectrogram-sox.png
$ sox output-aucat.flac -n spectrogram -o spectrogram-aucat.png
I'd certainly be interested in the ability to play audio in a way that avoids
resampling altogether, similar to what a user can do on FreeBSD with the
following sysctl tweaks:
# sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1
https://www.freebsd.org/cgi/man.cgi?query=sound&manpath=FreeBSD+13.1-RELEASE&format=html
That said, I understand that someone would have to write the code for that, and
right now I lack the know-how so my expectations are nil.
To end this mail, here are some relevant command outputs (note that these
weren't gathered at the time of testing, they're to show what the system
generally looks like):
# mixerctl -av
inputs.dac-2:3=94,94
inputs.dac-0:1=94,94
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off [ off on ]
record.adc-2:3=124,124
outputs.spkr_source=dac-2:3 [ dac-2:3 ]
outputs.spkr_mute=off [ off on ]
outputs.spkr_eapd=on [ off on ]
outputs.spkr2_source=dac-0:1 [ dac-2:3 dac-0:1 ]
outputs.spkr2_mute=off [ off on ]
outputs.spkr2_boost=off [ off on ]
inputs.mic=85,85
outputs.mic_dir=input-vr80 [ none input input-vr0 input-vr50 input-vr80
input-vr100 ]
outputs.hp_source=dac-0:1 [ dac-2:3 dac-0:1 ]
outputs.hp_mute=off [ off on ]
outputs.hp_boost=off [ off on ]
outputs.hp_eapd=on [ off on ]
record.adc-2:3_source=mic { mic }
record.adc-0:1_source=mic { mic }
outputs.mic_sense=unplugged [ unplugged plugged ]
outputs.hp_sense=unplugged [ unplugged plugged ]
outputs.spkr_muters=hp { hp }
outputs.master=95,95
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp { dac-2:3 dac-0:1 spkr
spkr2 hp }
Re: sndio and bit perfect playback
On Sun, Jan 08, 2023 at 10:56:31PM +0100, Jan Stary wrote: > On Oct 16 08:18:17, a...@caoua.org wrote: > > On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote: > > > On 10/14/22 11:21, Alexandre Ratchov wrote: > > > > Here are the measures of the aliasing noise using sine sweeps. Check > > > > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > > > > > > > https://arverb.com/pub/src/ > > > aucat(1) currently says > > BUGS >Resampling is low quality. > > Is this still considered to be the case? > IMO, it doesn't deserve the BUGS section anymore, I'll remove this sentence. Objections?
Re: sndio and bit perfect playback
On Oct 16 08:18:17, a...@caoua.org wrote: > On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote: > > On 10/14/22 11:21, Alexandre Ratchov wrote: > > > Here are the measures of the aliasing noise using sine sweeps. Check > > > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > > > > > https://arverb.com/pub/src/ aucat(1) currently says BUGS Resampling is low quality. Is this still considered to be the case?
Re: sndio and bit perfect playback
On Tue, 25 Oct 2022 16:44:59 +0200 Christian Weisgerber wrote: > Andre Smagin: > > > There is possibly one more use case for "bit-perfect". I have a small > > collection of surround sound (5.1, 4.1, quad, etc) recordings extracted > > from various DVDs, SACDs, and other sources. > > Yup. > I even have a commercially released DTS-CD lying around somewhere, > which is basically an ordinary CD except that the audio is encoded > as DTS and not PCM. > > > My desktop is connected to a receiver via optical SPDIF cable. To get > > the surround sound, I use mpd with 'device "snd/0"' option and Ario to > > control the mpd daemon. > > I'm curious, what's the actual audio hardware? azalia(4) or uaudio(4)? It is azalia, built-in on the motherboard (dmesg at the end). > > Bit depth does not seem to matter. I don't care about "bit-perfect", but > > only about sending the dts stream to the receiver as-is, which works. > > S/PDIF actually has a native depth of 20 bits per sample. There > are also 4 spare bits in the frame, which can optionally be used > to transport 24 bits. If an audio source provides only 16 bits per > sample, those are fit into the 20 bit frame with the remaining bits > unused. DTS and AC3 encodings for S/PDIF only use 16 bits. Ah, thank you for the explanation! I tried reading the DTS specification once, but it is way over my head. -- Andre Smagin OpenBSD 7.2-current (GENERIC.MP) #778: Mon Oct 10 22:34:04 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68596912128 (65419MB) avail mem = 66500554752 (63419MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6cf0 (59 entries) bios0: vendor American Megatrends International, LLC. version "A.I0" date 08/10/2022 bios0: Micro-Star International Co., Ltd. MS-7C37 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT MCFG HPET SSDT IVRS FPDT PCCT SSDT CRAT CDIT SSDT SSDT SSDT SSDT WSMT APIC SSDT acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP10(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 5950X 16-Core Processor, 3400.06 MHz, 19-21-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,
Re: sndio and bit perfect playback
Andre Smagin: > There is possibly one more use case for "bit-perfect". I have a small > collection of surround sound (5.1, 4.1, quad, etc) recordings extracted > from various DVDs, SACDs, and other sources. Yup. I even have a commercially released DTS-CD lying around somewhere, which is basically an ordinary CD except that the audio is encoded as DTS and not PCM. > My desktop is connected to a receiver via optical SPDIF cable. To get > the surround sound, I use mpd with 'device "snd/0"' option and Ario to > control the mpd daemon. I'm curious, what's the actual audio hardware? azalia(4) or uaudio(4)? > Bit depth does not seem to matter. I don't care about "bit-perfect", but > only about sending the dts stream to the receiver as-is, which works. S/PDIF actually has a native depth of 20 bits per sample. There are also 4 spare bits in the frame, which can optionally be used to transport 24 bits. If an audio source provides only 16 bits per sample, those are fit into the 20 bit frame with the remaining bits unused. DTS and AC3 encodings for S/PDIF only use 16 bits. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: sndio and bit perfect playback
Hi Misc, As the OP, i hope you will excuse the top-posting. Thanks for all the feedback and exciting discussions. Context/Backstory.. i was using that laptop as its the only system i have with a remaining working cd/dvd device, which just happened to have OpenBSD installed. The 'cdio cdrip' tooling was awesome and just worked, adding a few missing physical_2_digital albumns to my collection. (if only cdio cddbinfo was fully functional). this allows me to rip a cd, and listen back to it. So with that i guess i could run sndio with flags matching to cd bit rate of 44100k. this will be bit-perfect for my purpose, and make the dac light up green. I'll test this later this week. -SUB --- Original Message --- On Sunday, October 16th, 2022 at 4:22 PM, Alexandre Ratchov wrote: > > Sure, there is measurable aliasing. My questioning is: is it audible > in 99% of the cases? > > Remains the question, how to handle the 1% remaining. For now, > resampling off-line is the least annoying, IMHO. > > AFAIK, sample rate changes in the kernel are OK, at least in uaudio > driver. > > Now it's all in sndiod (or how to bypass sndiod to get bit-perfect > audio)
Re: sndio and bit perfect playback
On Fri, Oct 14, 2022 at 04:01:45PM -0400, Geoff Steckel wrote: > > > > I did simple A/B tests with music from CDs and my ears couldn't hear > > the aliasing noise. Try it. > Good a/b >x< tests for audio require extreme care to get accurate results. > Simple sine sweeps don't show IM distortion well. > In most cases numerically equal amounts of IM distortion are far more easily > noticed than harmonic distortions or simple noise (white, pink, etc.) Sure, there is measurable aliasing. My questioning is: is it audible in 99% of the cases? Remains the question, how to handle the 1% remaining. For now, resampling off-line is the least annoying, IMHO. > > Sometimes you just don't want to think about it (ex., when you debug > > audio stuff), so resampling off-line (or switching the device rate) > > still makes sense in certain cases. > This is the classic "why would you ever want to do that?" > "Just as good" is an opinion. > Other OSs can and do provide controls which allow setting the device > sample rate to whatever the device can do. > This user wants that to work. > > This means compiling a kernel with AUDIO_DEBUG Real Soon Now > and inserting a few more DPRINTFs. AFAIK, sample rate changes in the kernel are OK, at least in uaudio driver. Now it's all in sndiod (or how to bypass sndiod to get bit-perfect audio)
Re: sndio and bit perfect playback
On Sat, Oct 15, 2022 at 10:03:52PM +0200, Åke Nordin wrote: > On 10/14/22 11:21, Alexandre Ratchov wrote: > > Here are the measures of the aliasing noise using sine sweeps. Check > > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > > > https://arverb.com/pub/src/ > > Those are interesting results, indeed. Is there a write-up about the > testing method somewhere where I can read how to reproduce such tests? > Sorry, no detailed write-up, but I did the aliasing measurement roughly as follows. Example for 44.1kHz to 48kHz: First generate a sine sweep at 44.1kHz, up to half the sample rate: sox -V -r 44100 -n sweep-44100.aif synth 30 sin 0+22050 gain -6 the gain must be slightly reduced to avoid filter over-shoots which would clip and show the clipping distortion. Then, resample the file to 48kHz using aucat (it uses the same algorithm as sndiod): aucat -n -i sweep-44100.aif -r 48000 -c 0:0 -o sweep-44100-48000.aif And plot the spectrogram: sox sweep-44100-48000.aif -n spectrogram -o sweep-44100-48000.png sxiv sweep-44100-48000.png The column with the "linear" method is obtained by resampling using the old aucat version. The column with the "offline" method is obtained by resampling with sox instead of aucat. Let me know if you need more information or have suggestions.
Re: sndio and bit perfect playback
On 10/14/22 11:21, Alexandre Ratchov wrote: > Here are the measures of the aliasing noise using sine sweeps. Check > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > https://arverb.com/pub/src/ Those are interesting results, indeed. Is there a write-up about the testing method somewhere where I can read how to reproduce such tests? MfG, -- Åke Nordin , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN +46704660199
Re: sndio and bit perfect playback
On Fri, Oct 14, 2022 at 06:43:46PM +0200, Jan Stary wrote: > > > In my experience resampling quality in any particular implementation > > > is not guaranteed and can introduce significant artifacts. > > > Declaring a particular implementation "good enough" without > > > knowing more seems premature. > > > > Here are the measures of the aliasing noise using sine sweeps. Check > > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > > > https://arverb.com/pub/src/ > > > > I did simple A/B tests with music from CDs and my ears couldn't hear > > the aliasing noise. Try it. > > Does this bit of sndiod(8) still apply? > > BUGS >Resampling is low quality; down-sampling especially >should be avoided when recording. > AFAICS, aliasing is not audible in most desktop setups. People with pro equipment probably already avoid real-time resampling. So, if nobody objects, I'll drop it.
Re: sndio and bit perfect playback
On 10/14/22 05:21, Alexandre Ratchov wrote: On Thu, Oct 13, 2022 at 05:20:49PM -0400, Geoff Steckel wrote: If those don't work it's a (fixable) bug/not-yet-implemented. I've tried those settings with ambiguous results but not failure. My usb dacs don't have visible indicators & I don't have a USB protocol sniffer. Running audioctl during playback reveals the device sample rate. Running audioctl shows what the system thinks the device rate is. In my experience resampling quality in any particular implementation is not guaranteed and can introduce significant artifacts. Declaring a particular implementation "good enough" without knowing more seems premature. Here are the measures of the aliasing noise using sine sweeps. Check the figure for the 44.1kHz to 48kH conversion, the sndiod column: https://arverb.com/pub/src/ I did simple A/B tests with music from CDs and my ears couldn't hear the aliasing noise. Try it. Good a/b >x< tests for audio require extreme care to get accurate results. Simple sine sweeps don't show IM distortion well. In most cases numerically equal amounts of IM distortion are far more easily noticed than harmonic distortions or simple noise (white, pink, etc.) Sometimes you just don't want to think about it (ex., when you debug audio stuff), so resampling off-line (or switching the device rate) still makes sense in certain cases. This is the classic "why would you ever want to do that?" "Just as good" is an opinion. Other OSs can and do provide controls which allow setting the device sample rate to whatever the device can do. This user wants that to work. This means compiling a kernel with AUDIO_DEBUG Real Soon Now and inserting a few more DPRINTFs.
Re: sndio and bit perfect playback
> > In my experience resampling quality in any particular implementation > > is not guaranteed and can introduce significant artifacts. > > Declaring a particular implementation "good enough" without > > knowing more seems premature. > > Here are the measures of the aliasing noise using sine sweeps. Check > the figure for the 44.1kHz to 48kH conversion, the sndiod column: > > https://arverb.com/pub/src/ > > I did simple A/B tests with music from CDs and my ears couldn't hear > the aliasing noise. Try it. Does this bit of sndiod(8) still apply? BUGS Resampling is low quality; down-sampling especially should be avoided when recording. Jan
Re: sndio and bit perfect playback
On Thu, Oct 13, 2022 at 05:20:49PM -0400, Geoff Steckel wrote: > > If those don't work it's a (fixable) bug/not-yet-implemented. > I've tried those settings with ambiguous results but not failure. > My usb dacs don't have visible indicators & I don't have a > USB protocol sniffer. Running audioctl during playback reveals the device sample rate. > In my experience resampling quality in any particular implementation > is not guaranteed and can introduce significant artifacts. > Declaring a particular implementation "good enough" without > knowing more seems premature. Here are the measures of the aliasing noise using sine sweeps. Check the figure for the 44.1kHz to 48kH conversion, the sndiod column: https://arverb.com/pub/src/ I did simple A/B tests with music from CDs and my ears couldn't hear the aliasing noise. Try it. Sometimes you just don't want to think about it (ex., when you debug audio stuff), so resampling off-line (or switching the device rate) still makes sense in certain cases.
Re: sndio and bit perfect playback
On Thu, 13 Oct 2022 22:14:33 +0200 Alexandre Ratchov wrote: > On Thu, Oct 13, 2022 at 03:11:50AM +, s...@skolma.com wrote: > > in summary, audio works.. just not bit-perfectly :) > > does anyone know if SNDIO supports such mode ? and how i might configure it. > > bit-perfect is practical for one thing only: avoid questionings about > whether the processing adds audible noise & distortion. I've tryed > various hacks, including bypassing sndiod and neither was very > practical. > > IMHO, the sndiod resampler covers 99% of the cases. To handle the > remaining 1%, I just resample the files off-line. audio/sox is > excellent for that. > > So, I'd suggest you to add "-e s24" to sndiod_flags and resample > off-line when needed. > > HTH There is possibly one more use case for "bit-perfect". I have a small collection of surround sound (5.1, 4.1, quad, etc) recordings extracted from various DVDs, SACDs, and other sources. They are encoded in DTS and Dolby Digital formats, as plain WAV files, and "compressed" to flac format to prevent "smart" applications, such as ffmpeg, mpd, etc. from trying to decode them and convert to stereo. My desktop is connected to a receiver via optical SPDIF cable. To get the surround sound, I use mpd with 'device "snd/0"' option and Ario to control the mpd daemon. mpd decodes the top layer (flac), but stops there and sends DTS-wav to the sndiod without mangling it further. However, if sndiod's sample rate does not match that of the recording, it resamples the stream, which ruins the DTS and results in white noise. I found out that I have to restart sndiod with either 'sndiod_flags="-m play -r 44100"' or 'sndiod_flags="-m play -r 48000"' flags in /etc/rc.conf.local depending on the files I am playing, and then it gets to the receiver without issues. I have each music directory annotated with the sample rate used, like so: HAMLET: /storage $ ls music/dts/Pink\ Floyd/ (1970) Atom Heart Mother (Quadrophonic Vinyl Conversion) (Dolby Digital Quad 16-48) (1973) Dark Side of the Moon (Alan Parson's Mix) (DVD-Audio) (DTS 4.1 24-48) (1971) Echoes (Original 4.0 Quad Mix) (From Pink Floyd the Early Years 1965-1972, Volume 5) (DTS Quad 16-48) (1973) Dark Side of the Moon (Analogue Transfer From SACD) (DTS 5.1 16-44.1) (1971) Meddle (From Pink Floyd the Early Years 1965-1972, Volume 5) (DTS 5.1 16-48) (1994) The Division Bell (2014, Warner Music Group, 20th Anniversary Edition) (DTS 5.1 16-48) Live: (1974) Live at Pompeii (DTS Quad 24-48) For '16-48' and '24-48' (bit depth-samplerate), I start sndiod with sndiod_flags="-m play -r 48000" for '16-44.1', I restart sndiod with sndiod_flags="-m play -r 44100" Bit depth does not seem to matter. I don't care about "bit-perfect", but only about sending the dts stream to the receiver as-is, which works. -- Andre
Re: sndio and bit perfect playback
On 10/13/22 16:14, Alexandre Ratchov wrote: On Thu, Oct 13, 2022 at 03:11:50AM +, s...@skolma.com wrote: in summary, audio works.. just not bit-perfectly :) does anyone know if SNDIO supports such mode ? and how i might configure it. bit-perfect is practical for one thing only: avoid questionings about whether the processing adds audible noise & distortion. I've tryed various hacks, including bypassing sndiod and neither was very practical. IMHO, the sndiod resampler covers 99% of the cases. To handle the remaining 1%, I just resample the files off-line. audio/sox is excellent for that. So, I'd suggest you to add "-e s24" to sndiod_flags and resample off-line when needed. HTH There's code in the kernel down through uaudio.c to set sample rates. audioctl accepts a "rate" argument sndiod accepts a "rate" argument. The code in those and libsndio looks reasonable. If those don't work it's a (fixable) bug/not-yet-implemented. I've tried those settings with ambiguous results but not failure. My usb dacs don't have visible indicators & I don't have a USB protocol sniffer. In my experience resampling quality in any particular implementation is not guaranteed and can introduce significant artifacts. Declaring a particular implementation "good enough" without knowing more seems premature. geoff steckel
Re: sndio and bit perfect playback
On Thu, Oct 13, 2022 at 03:11:50AM +, s...@skolma.com wrote: > > > in summary, audio works.. just not bit-perfectly :) > does anyone know if SNDIO supports such mode ? and how i might configure it. > bit-perfect is practical for one thing only: avoid questionings about whether the processing adds audible noise & distortion. I've tryed various hacks, including bypassing sndiod and neither was very practical. IMHO, the sndiod resampler covers 99% of the cases. To handle the remaining 1%, I just resample the files off-line. audio/sox is excellent for that. So, I'd suggest you to add "-e s24" to sndiod_flags and resample off-line when needed. HTH
Re: sndio and bit perfect playback
> By the way, sndiod defaults to 48k as well. > > > eg music , brower video and system sounds. > > but is techncally up/down sampling based on feed. Forgot to say/rant: If you have a 44100 Hz linear PCM stereo wav file, and play it with aucat, and sndiod resamples it to 48 kHz (as I believe it does with the default sndiod -r rate), there is no way for you to hear the difference. Play the file with sndiod -r 48000, then with sndiod -r 44100 and tell me: are the trebles "crispy"? Are the middles "rich"? Or are they not, when it's not "bit-perfect"? Please.
Re: sndio and bit perfect playback
On Oct 13 03:11:50, s...@skolma.com wrote: > A questions about SNDIO and bit-perfect audio playback. > > I use a usb dac, audioquest dragonfly black 1.5, > and headphones to listen to my digitised music collection, > as i can conveniently move between my various devices. > > OpenBSD has detected this device dmesg? > and following FAQ13 i was able > to have working playback of .wav and .flac audio files with ease > via the various sndioctl commands. > tested successfully with aucat, and ogg123, > including other audio such as browser/yt. > The dac supports several native bit rates, This is the point where you should show the full output of mixerctl -av and audioctl. > and has a nice party_trick of changing physical logo colour > based on the feed, the main ones being: never mind the logo colour, show the actual audio settings, as in mixerctl and audioctl > 16bit / 44.1k, green. (cd quality) > 24bit / 48k, blue (dvd quality) > 24bit / 88.2k, orange, > 24bit / 96k pink. Are all of these stereo, or are some of them multichannel? > In my testing, windows, mac, freebsd, openbsd, and linux > all default to the 48k - blue mode allowing mulitple input streams. Multiple input streams have nothing to do with the above settings. By default, sndio will play what you feed it, mixing from multiple inputs - as I suppose other audio systems do on other OSes; this is not a property of the audio device. By the way, sndiod defaults to 48k as well. > eg music , brower video and system sounds. > but is techncally up/down sampling based on feed. Of course: how else are you gonna play a 8 kHZ audio file when the device cannot do 8 kHz? > For bit perfect to work correctly.. Stop right there: what do you mean by bit perfect? The bits stored in a flac file are not the same bits that arrive at the audio device to be played. Are you just concerned with the upsampling? (Or downsampling? Meaning you have music stored in more than 24bit @ 96 kHz? > normally the audio subsystem What subsytem? sndio? > would be configured to operate > in exclusive mode. where only the music would be the output. Meaning what? To the running sndiod, an input is an input, there;s nothing distinguishing "music". What you probably mean is giving e.g. ogg123 exclusive rights to open the audio device, resp. exclusive rights to be sndiod's input, so that nothing else is playing while ogg123 is playing. Is that what you mean? (Even so, the bits of the ogg file are not the bits that reach the audio device. Drop the "bit-perfect" lingo, this is imho about exclusive audio device access.) > does anyone know if SNDIO supports such mode? > and how i might configure it. I suppose you have already read sndiod(8) in its entirety ... (You can also not run sndiod: then only one audio player will have access to the underlying device.) Jan
sndio and bit perfect playback
hi Misc, A questions about SNDIO and bit-perfect audio playback. I use a usb dac, audioquest dragonfly black 1.5, and headphones to listen to my digitised music collection, as i can conveniently move between my various devices. OpenBSD has detected this device and following FAQ13 i was able to have working playback of .wav and .flac audio files with ease via the various sndioctl commands. tested successfully with aucat, and ogg123, including other audio such as browser/yt. The dac supports several native bit rates, and has a nice party_trick of changing physical logo colour based on the feed, the main ones being: 16bit / 44.1k, green. (cd quality) 24bit / 48k, blue (dvd quality) 24bit / 88.2k, orange, 24bit / 96k pink. In my testing, windows, mac, freebsd, openbsd, and linux all default to the 48k - blue mode allowing mulitple input streams.. eg music , brower video and system sounds. but is techncally up/down sampling based on feed. For bit perfect to work correctly.. normally the audio subsystem would be configured to operate in exclusive mode. where only the music would be the output. think locking-mode. i have this working in linux via alsa on my main laptop and pc... and appears freebsd oss supports this too. but i do enjoy openbsd on my old sonyvaio. in summary, audio works.. just not bit-perfectly :) does anyone know if SNDIO supports such mode ? and how i might configure it. thanks in advance. -sub OpenBSD 7.1 on a 2010 sony vaio vpcs113fg.
