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@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-userReceived on Wed Apr 12 08:15:01 2017
This archive was generated by hypermail 2.1.8 : Wed Apr 12 2017 - 08:15:01 EEST