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
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.
Query on openrsync(1)
OpenBSD newbie here. While trying to backup my OpenBSD configs to my Arch Linux box, I noted a discrepancy between the openrsync(1) manpage examples and what I encountered. The steps to reproduce are as follows: ``` $ uname -a OpenBSD oberon.taranjali.org 7.2 GENERIC.MP#758 amd64 $ touch foo bar $ rsync -av foo bar abhishek@192.168.1.3:/home/abhishek ksh: rsync: not found $ openrsync -av foo bar abhishek@192.168.1.3:/home/abhishek Enter passphrase for key '/home/abhishek/.ssh/id_ed25519': Transfer starting: 2 files bar foo Transfer complete: 56 B sent, 187 B read, 0 B file size ``` The EXAMPLES section for the openrsync(1) specifically mention rsync and not openrsync. I did find an earlier thread related to this issue: https://marc.info/?l=openbsd-misc=162123821229046=2 The suggestion from that thread seems to be to use the rsync package instead of openrsync. Is this still the case? And if not, shouldn't the openrsync(1) manpage examples invoke openrsync instead of rsync? Thank you for your time and consideration. -- Abhishek Chakravarti abhis...@taranjali.org | Kolkata, IN fifthestate.co.in | refpersys.org | taranjali.org
Re: IKEv1 and IKEv2 coexistence
On 2023-01-09, jean-yves boisiaud wrote: > Hello, > > I have an OpenBSD firewall running IPSEc with IKEv1. > > As said here https://marc.info/?l=openbsd-misc=163819895506660=2 > isakmpd cannot coexist with IKEv2. > > But I have several IPs, could I use one IP for IKEv1 and another one for > IKEv2 ? Not with iked/isakmpd unless you run one of them in a VM. -- Please keep replies on the mailing list.
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: terminal emulators
Il Mar 10 Gen 2023, 19:38 Justin Muir ha scritto: > Hi all, > > Just for the security-minded: run ldd xterm | wc -l > Then do the same for sakura, alacritty or whatever your favourite term > happens to be. > > I'm still mulling over whether I should straight up switch to the one with > the least dependencies or just continue with xterm. > > Any thoughts? > Xterm is pledged, the other terminal emulators are not. Cheers, David
terminal emulators
Hi all, Just for the security-minded: run ldd xterm | wc -l Then do the same for sakura, alacritty or whatever your favourite term happens to be. I'm still mulling over whether I should straight up switch to the one with the least dependencies or just continue with xterm. Any thoughts? tia!
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
> > # 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
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
Re: terminal emulators
Hi, You could also try st, also pledged. :wq, G On 10.01.2023 20:15, David Coppa wrote: > Il Mar 10 Gen 2023, 19:38 Justin Muir ha scritto: > > > Hi all, > > > > Just for the security-minded: run ldd xterm | wc -l > > Then do the same for sakura, alacritty or whatever your favourite term > > happens to be. > > > > I'm still mulling over whether I should straight up switch to the one with > > the least dependencies or just continue with xterm. > > > > Any thoughts? > > > > Xterm is pledged, the other terminal emulators are not. > > Cheers, > David
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
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(, f->endpos - sizeof(hdr.riff)); memcpy(hdr.fmt_hdr.id, wav_id_fmt, 4); le32_set(_hdr.size, sizeof(hdr.fmt)); - le16_set(, 1); + le16_set(, WAV_FMT_EXT); le16_set(, f->nch); le32_set(, f->rate); le32_set(, f->rate * f->par.bps * f->nch); le16_set(, f->par.bps * f->nch); le16_set(, f->par.bits); + le16_set(, + WAV_FMT_EXT_SIZE - WAV_FMT_SIZE - sizeof(hdr.fmt.extsize)); + le16_set(, f->par.bits); + le16_set(, 1); + memcpy(, wav_guid, sizeof(hdr.fmt.guid)); memcpy(hdr.data_hdr.id, wav_id_data, 4); le32_set(_hdr.size, f->endpos - f->startpos); return afile_writehdr(f, , sizeof(struct wav_hdr));
