Date: Tue, 7 Aug 2018 09:23:26 +0200 From: Hans Petter Selasky <hps@selasky.org> To: =?UTF-8?Q?Goran_Meki=c4=87?= <meka@tilda.center>, freebsd-multimedia@freebsd.org Subject: Re: Choppy audio using virtual_oss Message-ID: <57293b09-97c6-8b89-24eb-2497529f2ba5@selasky.org> In-Reply-To: <20180807003145.7m55dlakppucpkt2@thinker.home.meka.rs> References: <20180807003145.7m55dlakppucpkt2@thinker.home.meka.rs>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/07/18 02:31, Goran Mekić wrote: > Hello, > > To be honest, I'm not sure it's virtual_oss' fault, but here are the > symptoms. When I use mpv to watch video, it glitches and renders really > slowely. When I run jackd and then mpv, everything is fine. Note, > though, that mpv is not compiled with jack support, so this is really > weird. When ardour5 loads a song with "lots" of tracks (around 30-40), > the song plays extremely choppy, although I recorded the whole song last > year using FreeBSD and ardour, so I'm absolutely positive it worked on > the same hardware/software. Here's some relevant info about OS config: Hi, First of all are you using the latest version of virtual_oss from ports? There was a minor ODELAY() fix recently. Second, can you check the CPU usage of virtual_oss when the sound is choppy? > > sysctl kern.timecounter.alloweddeviation=0 > sysctl hw.usb.uaudio.buffer_ms=2 > sysctl dev.pcm.0.play.vchans=0 > sysctl dev.pcm.0.rec.vchans=0 > sysctl dev.pcm.1.play.vchans=0 > sysctl dev.pcm.1.rec.vchans=0 > virtual_oss -T /dev/sndstat -S -i 8 -C 18 -c 18 -r 88200 -b 32 -s 384 -f /dev/dsp1 -c 2 -d dsp -c 18 -d vdsp.jack -t vdsp.ctl -M i,0,8,0,0,0 -M i,0,9,0,0,0 -M i,6,8,0,0,0 -M i,6,9,0,0,0 > jackd -r -d oss -r 88200 -C /dev/vdsp.jack -P /dev/vdsp.jack -i 18 -o 18 jackd also accepts -p option for number of samples buffering, -p 384. > What I didn't try is "sysctl hw.snd.latency=0", which I can try > tomorrow, but I'm not sure it should make any difference. > > How can I figure our what's causing this if hw.snd.latency doesn't fix > it? Also, why is "-s 384" recommended? 384/88200 = 0.0043537 seconds buffering. I suggest you use a buffer size which is a factor of the buffer_ms value, like: 88200 * 0.002 = 177 Personally I think you should use 4ms buffering when you deal with that many channels to avoid underflows. --HPS > To be more precise, why not 2^n, > but 2^n*3? While I used Linux, I know I read USB audio interfaces should > use "-n 3" for jackd, but I couldn't find the reason why, and I just > guess it has something to do with the value of 384. Of course, I > tried adding that to my jackd command, but it didn't help. I tried > combining "-s 512" for virtual_oss and "-n 3" for jackd, but no luck > either. > > If I can provide any other info, please tell me. > > Regards, > meka >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57293b09-97c6-8b89-24eb-2497529f2ba5>