On Tue, April 11, 2017 9:11 am, Antony Gelberg wrote: > Apr 11 16:28:09 cubase kernel: [108661.803326] usb 3-3: 1:2: cannot get > freq at ep 0x1 > Apr 11 16:28:09 cubase kernel: [108661.805662] usb 3-3: 2:2: cannot get > freq at ep 0x82 I also found those messages when I searched my kernel log, but I have never noticed any problem while using my Lexicon Lambda, so I think they must be informational, not indicating a problem. > I also noticed when starting jack: > Apr 10 11:46:50 cubase pulseaudio[23745]: [pulseaudio] module-jack-sink.c: > JACK error >Cannot use real-time scheduling (RR/5)(1: Operation not > permitted)< That seems more likely a problem with jack-sink. Do you notice any problems if you run jack without pulse connected through jack-sink? Perhaps the problem is only pulseaudio and not related to jack. I did remember that in the past I had problems when running pulse at a default sample rate of 44100, most audio for video is at a rate of 48000, I think that the pulse sample rate conversion routines were not very efficient. Once I changed to running pulse at a default rate of 48000 I had no more problems, even when running jackd at 44100. > At the time of the messages, qjackctl was suddenly using 25% of my decent > i5 CPU.When I checked the log, it was full of messages like: > > Tue Apr 11 16:28:09 2017: Jack: ALSA XRun wait_status = 0 > Tue Apr 11 16:28:09 2017: Jack: JackSocketServerChannel::Execute : > fPollTable i = 1 fd = 12 > Tue Apr 11 16:28:09 2017: Jack: JackRequest::Notification > Tue Apr 11 16:28:09 2017: Jack: JackEngine::ClientNotify: no callback for > notification = 3 My suspicion is that pulseaudio jack-sink is not meeting the timing requirements for some reason and is causing an underrun. I suggest running only jack applications with jack-sink disconnected from all jack connections, or even unloaded completely, and see if you can isolate whether the problem is with jackd through ALSA, or is only when pulse is also used with jackd. If the problem only occurs with pulse, check the default sample rate, and change to 48000 if that is not currently set as the default. If pulse is already set to 48000, check your buffer size. When not doing anything latency sensitive (which is most of the time) I run with settings of 1024 frames per period, 3 frames per buffer. This is what I have as sample rate setting in /etc/pulse/daemon.conf: default-sample-format = s24le default-sample-rate = 48000 alternate-sample-rate = 44100 -- Chris Caudle _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
