15 Aug
2015
15 Aug
'15
12:39 a.m.
Background.
I often use my 'office' machine (64 bit dial core Intel - debian 8) to do
experimental work on audio software as I don't want to take risks with my DAW.
Sometimes I use a KA6, other times the motherboard sound depending on what I
want to check. However, I've got into the habit of leaving the KA6 plugged in
anyway.
Recently I've noticed that if I have jack running through the motherboard
audio, I get exactly 1 Xrun approximately every 11 minutes. This doesn't
happen if the KA6 is not plugged in, nor does it happen if I route jack's audio
through it.
If this was some USB issue I would have expected it to be there when routing
through the KA6 as well.
Any ideas?
As an aside, I can run the KA6 at 1/2 the buffer size of the motherboard audio
and still get no Xruns, when the latter is getting quite croaky.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
15 Aug
15 Aug
1:41 a.m.
On Fri, 14 Aug 2015 23:39:04 +0100, Will Godfrey wrote:
If this was some USB issue I would have expected it to
be there when
routing through the KA6 as well.
USB might have a higher priority, than the integrated device, hence
the xruns for the integrated device and non when using the USB device.
Are you using rtirq to set up the priorities?
Regards,
Ralf
1:52 a.m.
On Sat, 15 Aug 2015 01:41:37 +0200, Ralf Mardorf wrote:
On Fri, 14 Aug 2015 23:39:04 +0100, Will Godfrey
wrote:
PS: Perhaps the KA6 checks something, when it's not used.
If this was some USB issue I would have expected
it to be there when
routing through the KA6 as well.
USB might have a higher priority, than the integrated device, hence
the xruns for the integrated device and non when using the USB device.
Are you using rtirq to set up the priorities? 
4:32 a.m.
On Fri, 14 Aug 2015, Will Godfrey wrote:
Background.
I often use my 'office' machine (64 bit dial core Intel - debian 8) to do
experimental work on audio software as I don't want to take risks with my DAW.
Sometimes I use a KA6, other times the motherboard sound depending on what I
want to check. However, I've got into the habit of leaving the KA6 plugged in
anyway.
Recently I've noticed that if I have jack running through the motherboard
audio, I get exactly 1 Xrun approximately every 11 minutes. This doesn't
happen if the KA6 is not plugged in, nor does it happen if I route jack's audio
through it.
My first thought was a media clock missmatch. An HDA audio if may have
more than one media clock. I have a laptop where the internal mic is 48k
only while the linein/out can be adjusted from 44k1 to 96k. I am pretty
sure the internal mic clock does not match line in/out even at 48k. But,
the problem is not always there.
If this was some USB issue I would have expected it to be there when routing
through the KA6 as well.
Any ideas?
Is pulse running? I have had a similar problem: pulse is connected to
internal (not using it for anything, just connected) Pulse bridged to
jack, and playing through jack then through ice1712 device... trouble.
Configure pulse with all device profiles to "off"... no problems. I think
pulse was trying to service jacksink/source at the same time as the
"unused" interface.
In my opinion, the trick to happiness with pulseaudio in a jack system is
to turn all devices off in pulse. (I want to try blacklisting the PA ALSA
module) and run jackdbus all the time. (jack_control with jackdbus allows
changing anything in jack while "running" though not glitchless changes
;) )
As an aside, I can run the KA6 at 1/2 the buffer size
of the motherboard audio
and still get no Xruns, when the latter is getting quite croaky.
The best I have gotten my HDA to go is 64/3 (64/2 not). Even my 2 channel
usb1.1 AI does better than that.
--
Len Ovens
www.ovenwerks.net
11:27 p.m.
Thanks for your thoughts guys.
Clock mismatch was the clue :o
I had been a bit lazy. While switching the output device I'd neglected to also
switch the input device, so jack was seeing two slightly different 48kHz
clocks. Switch both at the same time and the problem disappears.
As a matter of curiosity I wonder if we can work out what the actual difference
is. Would the Xrun occur when there was a one frame difference, one period, or
1 buffer? It's running at 256 frames per period and 2 periods per buffer. The
xruns occur every 11 minutes (and a few seconds).
As I said at the start, this is my 'office' machine and has *no* optimisations.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
16 Aug
16 Aug
12:27 a.m.
On Sat, 15 Aug 2015, Will Godfrey wrote:
Clock mismatch was the clue :o
I had been a bit lazy. While switching the output device I'd neglected to also
switch the input device, so jack was seeing two slightly different 48kHz
clocks. Switch both at the same time and the problem disappears.
:)
As a matter of curiosity I wonder if we can work out what the actual difference
is. Would the Xrun occur when there was a one frame difference, one period, or
1 buffer? It's running at 256 frames per period and 2 periods per buffer. The
xruns occur every 11 minutes (and a few seconds).
While the xrun would happen at a buffer read boundary, the offending IF
would only have to be 1 frame out to be late. (if my thinking is correct)
So the timing of the xrun would be the difference in clock plus the size
of a buffer (or portion there of). That is, I think it would be unlikely
the time between xruns would be exactly the same. The minimum time between
xruns is the value I would use.
Now which one is faster?
--
Len Ovens
www.ovenwerks.net
10:06 a.m.
On Sat, Aug 15, 2015 at 10:27:33PM +0100, Will Godfrey wrote:
As a matter of curiosity I wonder if we can work out
what the actual difference
is. Would the Xrun occur when there was a one frame difference, one period, or
1 buffer? It's running at 256 frames per period and 2 periods per buffer. The
xruns occur every 11 minutes (and a few seconds).
If you assume that an xrun occurs when the difference in samples is
one period, then the difference in sample frequency is P / T, with
P the period and T the time in seconds between xruns.
With the values you give:
dF = 256 / (11 * 60) =~ 0.39 Hz.
You can measure this easily using jack_delay (or jack_iodelay).
The change in measured latency, in samples, per second is the
difference in sample rate.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
5:04 p.m.
On Sun, 16 Aug 2015 08:06:00 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, Aug 15, 2015 at 10:27:33PM +0100, Will Godfrey
wrote:
Thanks.
Considering this is a mid-range unit V 'standard' motherboard sound, that's
actually rather impressive.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
As a matter of curiosity I wonder if we can work
out what the actual difference
is. Would the Xrun occur when there was a one frame difference, one period, or
1 buffer? It's running at 256 frames per period and 2 periods per buffer. The
xruns occur every 11 minutes (and a few seconds).
If you assume that an xrun occurs when the difference in samples is
one period, then the difference in sample frequency is P / T, with
P the period and T the time in seconds between xruns.
With the values you give:
dF = 256 / (11 * 60) =~ 0.39 Hz.
You can measure this easily using jack_delay (or jack_iodelay).
The change in measured latency, in samples, per second is the
difference in sample rate.
Ciao,
3389
days inactive
3391
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Fons Adriaensen -
Len Ovens -
Ralf Mardorf -
Will Godfrey