Dear Tetsuya, On 2020-03-20, Tetsuya Isaki wrote: > At Fri, 20 Mar 2020 08:08:37 +0200, > Yorick Hardy wrote: > > It seems to be stuck in select (or poll, I did not check the source) > > in portaudio. > > Yeah, I'm just looking this in this week. > poll()/select() before read() doesn't work correctly now. > I will fix it. > > > Updating audio/portaudio from portaudio-190600.20161030nb1 to > > portaudio-190600.20161030nb2 > > fixes the problem (maybe because of the patch to disable non-blocking I/O > > ?). > > I looked it right now. And it looks bad strategy. > He should have reported it first... > > > Now 44100 MHz does not sound right (I will send the example off-list), but > > 48000 MHz is fine (this is the same behaviour as audiorecord). > > I heard it but unfortunately I don't know expected status. > It sounded like analog noise or environmental noise. > > > Anyway, if you want to record with pure 44100Hz, you need to > set the hardware 44100Hz mode using audiocfg(1) command: > # audiocfg set <index> r slinear_le 16 2 44100 > > On NetBSD7 (or prior), if you record 44100Hz, the kernel set > the hardware 44100Hz, because it was single audio system. > > On NetBSD9 (or later), multiple recorder apps can be run > simultaneously. So even if your single app want to record > 44100Hz, the kernel can not change the hardware frequency. > The kernel converts from the hardware frequency to your > requested frequency (if different). > In-kernel frequency conversion is simple (and fast and small) > than what userland rich apps does (and I personally think that > such rich operation should be done by userland). > > You need to a)change the hardware format (by audiocfg) or > b)record as the hardware format ("audiocfg list" displays) > and convert it by userland rich converter. > > Thanks, > --- > Tetsuya Isaki <is...@pastel-flower.jp / is...@netbsd.org>
Thanks! I think Nia mentioned this also, but somehow I did not fully understand the role of audiocfg. -- Kind regards, Yorick Hardy