10 Apr
2007
10 Apr
'07
1:30 a.m.
Hey List,
So my initial concerns that the HDA Intel audio card shares the IRQ
with ohci1394 seem to have manifested themselves. Using the kernel
option pci=noacpi initially put most of my devices on IRQ11, but then
I was able to move them around using the BIOS. Unfortunately, whenever
I change the IRQs around, HDA Intel, ohci1394, and uhci_hcd:usb2 all
seem to move together, which to me indicates that there's some
lower-level hardware connection between the three of them.
This means that I get loads of xruns if I try to run jackd with a
firewire hard drive plugged in, which is a pain because I bought this
enclosure specifically so that I would have access to the hard drive
that has all my session files on it.
Can anyone think of any possible way that I can use the internal sound
card with my firewire hard drive? Maybe some deeper way of
manipulating the IRQs that I'm not aware of?
I'm planning on getting a PCMCIA sound card at some point, but after
dropping 1,400 on this laptop my extra funds are a little tight for a
while.
Thanks,
spencer
10 Apr
10 Apr
2:18 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Maybe some deeper way of
manipulating the IRQs that I'm not aware of?
nope.looks like it's hardwired.
I'm planning on getting a PCMCIA sound card at
some point, but after
dropping 1,400 on this laptop my extra funds are a little tight for a
while.
go usb. better supported and cheaper too probably.i use a m-audio transit.
works well.
g.
7:50 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Am Dienstag, 10. April 2007 schrieb Geoff Beasley:
Or firewire. Sounds strange as fw is already making problems but it may be
better. But test it before-hand, either with a friends device or at your
local dealer...
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
I'm
planning on getting a PCMCIA sound card at some point, but after
dropping 1,400 on this laptop my extra funds are a little tight for a
while.
go usb. better supported and cheaper too probably.i use a m-audio transit.
works well. 
8:08 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Geoff Beasley wrote:
indeed. - they "might" be firmware-programmable, but usually they are
hardcoded in the PCB. - in a few years your kid might find DIY
instructions to how to tweak that old R60.. ;)
Maybe some
deeper way of
manipulating the IRQs that I'm not aware of?
nope.looks like it's hardwired.
> I'm planning on getting a PCMCIA sound card at
some point, but after
> dropping 1,400 on this laptop my extra funds are a little tight for a
> while.
PCMCIA is ok, but not great for low latency. (adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
go usb. better supported and cheaper too probably.i
use a m-audio transit.
works well.
usb will get you only 2 channels (full-duplex @48kHz, or half-duplex at
96kSPS, due to USB1.1 bandwidth limitations. IIRC there's no USB2-audio
standard.
The hardwired thinkpad PCI-IRQ's are a bit annoying for pro-audio, but
after all it's possible! - thinkpad X60s (guess it's similar to the
R60): the build in hda soundcard works fine with
`jackd -R -P70 -dalsa -dhw:0,0 -r48000 -p64 -n3` !!!
but the sound quality is.. mmmh great for telephone & entertaining music.
If I use the wireless (ipw3945 - same IRQ) extensively I get xruns.. a
Firewire drive might cause similar issues, I have not tested that. - The
easiest solution is to connect your firewire disk to a 2nd machine and
export it via eth-wire (or USB?)
If you are into hacks&tweaks you might be able to get a useable system,
though: tweak the PCI bus settings (try the inverse of what paul's
setpci script does: If the firewire device blocks the bus for too long,
the audio on the same IRQ won't have a chance.), disable DMA for the FW
harddisk (is that possible? - maybe try different IO schdulers or limit
the disk-i/o bandwidth in favor of polling it nicely?, does the
fw-device driver have a PCI/split-transaction on/off option?) - IIRC
there's a way to re-nice kernel threads, but nothing that any sane
audio-engineer would want to try...
As for Sound: I rarely use the SD-reader (sdhci:slot0 - BTW. unloading
the module saves power!) so I connect a USB UA-25 to either IRQ22 or
IRQ23. even if it's the only device on that bus I get rare xruns on 64
frames/period. but a robust setup with `jackd -R -P 70 -d alsa -d hw:1
-p 256 -r 48000` makes this Thinkpad a great machine for
stereo/binaural audio work and fun! - (recap: the Dell D820 seems
somewhat better suited for pro-audio, and a Vaio sz3 is similarly good,
but sony&linux requires a little more some devotion..)
thinkpad x60s:
CPU0 CPU1
0: 352029528 0 IO-APIC-edge timer
1: 1251013 0 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 65043220 0 IO-APIC-fasteoi acpi
12: 10126775 0 IO-APIC-edge i8042
20: 35583442 20485440 IO-APIC-fasteoi yenta,
i915@pci:0000:00:02.0, uhci_hcd:usb1
21: 200293604 250337407 IO-APIC-fasteoi ohci1394, ipw3945, HDA
Intel, uhci_hcd:usb2
22: 65491123 0 IO-APIC-fasteoi sdhci:slot0, uhci_hcd:usb3
23: 745166 1065462 IO-APIC-fasteoi ehci_hcd:usb5, uhci_hcd:usb4
218: 1670650 179 PCI-MSI-edge eth1
219: 810037 3174745 PCI-MSI-edge libata
NMI: 0 0
LOC: 107326912 241228138
ERR: 0
MIS: 0
8:34 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Robin Gareus <robin(a)gareus.org> wrote:
PCMCIA is ok, but not great for low latency. (adds one
extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details.
So if you are for low latency, PCI/PCMCIA is unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME MultifaceII.
Ask somebody to jdelay their Firewire card.
Regards,
Dmitry.
9:28 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Dmitry Baikov wrote:
On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
good point. now I start to remember the protocol mess and overhead of
1394 audio. - and hope I'll forget about it again soon.. ;)
PCMCIA is ok, but not great for low latency.
(adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details. So if you are for low latency, PCI/PCMCIA is
unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME
MultifaceII.
why not? a LAU-Poll can launch a "known to work professional gnu/linux
sound setups and their specs&tweaks" wiki page.. I wanted to pull out
some information of prev. emails and x-link archived emails to the
linuxaudio.org wiki... maybe next weekend..
Ask somebody to jdelay their Firewire card.
it's not easy to interpret jdelay's output, is it?
i get a lot of those running jdelay at 48kSPS -f64 -n2 for the UA-25.
24404.495 frames ?? Inv
24404.345 frames ??
24404.241 frames ?? Inv
24404.181 frames ??
sometimes it "flips" and displays
44664.987 frames ??
43225.215 frames ?? Inv
8585.183 frames ??
or other weird jumps that all add up to 48k. Then goes back to repeat
the 24400 pattern. - i can tell that 24400/48000 is not the latency ;p
and guess it means a total round trip latency of around 800 frames or 16 ms.
btw. if i move a headphone relative to the mic, jdelay allows to track
its distance with about a 2cm accuracy. how cool!
the built-in HDA reports:
59328.024 frames ??
59328.024 frames ?? Inv
59328.024 frames ??
59328.024 frames ?? Inv
59328.024 frames ??
59328.024 frames ?? Inv
59328.024 frames ??
59328.024 frames ?? Inv
9608.520 frames ??
9608.643 frames ?? Inv
9608.536 frames ?? Inv
9608.549 frames ??
9608.485 frames ?? Inv
9608.449 frames ??
59328.154 frames ?? Inv
59328.147 frames ??
8584.172 frames ?? Inv
59328.193 frames ??
not sure how to make sense of that, yet. something's oscillating over
here, where's the javascript-power-spectrum-paste-bin? lol. ;)
#robin
9:52 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Am Dienstag, 10. April 2007 schrieb Robin Gareus:
Dmitry Baikov wrote:
No, you remember the mess from 1394-detection. Protocol-overhead allows 2x64
here with my presonus firepod...
And ppalmers stated that firewire will be much better than netjack because of
fixed latency and guaranteed bandwidth and reaction time.
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
good point. now I start to remember the protocol mess
and overhead of
1394 audio. - and hope I'll forget about it again soon.. ;) PCMCIA is ok, but not great for low latency.
(adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details. 
10:21 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Arnold Krille wrote:
Am Dienstag, 10. April 2007 schrieb Robin Gareus:
The streaming protocol doesn't introduce
problems with respect to
latency. The mess is indeed the detection procedure.
Dmitry Baikov wrote:
No, you remember the mess from 1394-detection. Protocol-overhead allows 2x64
here with my presonus firepod... On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
good point. now I start to remember the protocol mess
and overhead of
1394 audio. - and hope I'll forget about it again soon.. ;) PCMCIA is ok, but not great for low latency.
(adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details. And ppalmers stated that firewire will be much better
than netjack because of
fixed latency and guaranteed bandwidth and reaction time.
Compared to netjack we
will totally rule :). But that's not for the next
release.
Pieter
10:26 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Robin Gareus wrote:
Dmitry Baikov wrote:
Stupid question maybe,
but did you set it up correctly? It's hard to
imagine that such a simple util would be broken for you but not for me.
Is the input gain correct?
On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
good point. now I start to remember the protocol mess and overhead of
1394 audio. - and hope I'll forget about it again soon.. ;)
PCMCIA is ok, but not great for low latency.
(adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details. So if you are for low latency, PCI/PCMCIA is
unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME
MultifaceII.
why not? a LAU-Poll can launch a "known to work professional gnu/linux
sound setups and their specs&tweaks" wiki page.. I wanted to pull out
some information of prev. emails and x-link archived emails to the
linuxaudio.org wiki... maybe next weekend..
Ask somebody to jdelay their Firewire card.
it's not easy to interpret jdelay's output, is it?
i get a lot of those running jdelay at 48kSPS -f64 -n2 for the UA-25.
24404.495 frames ?? Inv
24404.345 frames ??
24404.241 frames ?? Inv
24404.181 frames ??
sometimes it "flips" and displays
44664.987 frames ??
43225.215 frames ?? Inv
8585.183 frames ??
or other weird jumps that all add up to 48k. Then goes back to repeat
the 24400 pattern. - i can tell that 24400/48000 is not the latency ;p
and guess it means a total round trip latency of around 800 frames or 16 ms.
If the
UA's latency is 800frames or 16ms @ 2x64, I can definitely say
that FireWire is WAY better, as in: 400 frames less latency for the same
buffer settings.
btw. if i move a headphone relative to the mic, jdelay allows to track
its distance with about a 2cm accuracy. how cool!
Use a patch cable! I don't
think jdelay is made with a Headphones->Mic
setup in thought.
Pieter
10:52 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Tue, Apr 10, 2007 at 02:20:32PM +0200, Pieter Palmers wrote:
Robin Gareus wrote:
> 24404.495 frames ?? Inv
> 24404.345 frames ??
> 24404.241 frames ?? Inv
> 24404.181 frames ??
The ?? mean that jdelay doesn't trust the signal. This is confirmed
by the frequent polarity inversions - jdelay tries to find out
which of the two polarities is correct and can't decide.
The reason could be either insufficient level (unlikely, as jdelay
can work with very noisy signals), or a frequency-dependent delay.
Jdelay uses phase measurements of a number of tones. The ?? mean
that the results are in contradiction. Try to verify the signal
path.
--
FA
Follie! Follie! Delirio vano è questo !
3:04 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Fons Adriaensen wrote:
On Tue, Apr 10, 2007 at 02:20:32PM +0200, Pieter
Palmers wrote:
I'll try again with a proper setup! I've used a [left]-sennheiser
headphone-speaker, and thinkpad's build-in mic ; and a Neumann Tube with
the UA25.
I've played with the input and output levels watching with bitscope, but
could not get the '??' go away for either mic (also the built-in speaker
did not do the trick). - but the measured/displayed values are
consistent, even though the scale/interpretation is wrong. - anyway I
did not try harder than 10 mins and did not yet read jdelays manual..
anyway, I remember playing with a non '??' jdelay - around last summer.
can that be? maybe it was aliki. how old is jdelay ? ;)
more later,
robin
PS. jdelay beats `xmms tone://12000` in the neighbor-annoyance poll: 2
vs. 1 (out of 5 here in the office)!
Robin Gareus wrote:
> 24404.495 frames ?? Inv
> 24404.345 frames ??
> 24404.241 frames ?? Inv
> 24404.181 frames ??
The ?? mean that jdelay doesn't trust the signal. This is confirmed
by the frequent polarity inversions - jdelay tries to find out
which of the two polarities is correct and can't decide.
The reason could be either insufficient level (unlikely, as jdelay
can work with very noisy signals), or a frequency-dependent delay.
Jdelay uses phase measurements of a number of tones. The ?? mean
that the results are in contradiction. Try to verify the signal
path.
3:35 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Tue, Apr 10, 2007 at 07:04:36PM +0200, Robin Gareus wrote:
Fons Adriaensen wrote:
I missed the start of this thread, so I don't know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
On Tue, Apr 10, 2007 at 02:20:32PM +0200, Pieter
Palmers wrote:
I'll try again with a proper setup! I've used a [left]-sennheiser
headphone-speaker, and thinkpad's build-in mic ; and a Neumann Tube with
the UA25. Robin Gareus wrote:
> 24404.495 frames ?? Inv
> 24404.345 frames ??
> 24404.241 frames ?? Inv
> 24404.181 frames ??
The ?? mean that jdelay doesn't trust the signal. This is confirmed
by the frequent polarity inversions - jdelay tries to find out
which of the two polarities is correct and can't decide.
The reason could be either insufficient level (unlikely, as jdelay
can work with very noisy signals), or a frequency-dependent delay.
Jdelay uses phase measurements of a number of tones. The ?? mean
that the results are in contradiction. Try to verify the signal
path.
anyway, I remember playing with a non '??'
jdelay - around last summer.
can that be? maybe it was aliki. how old is jdelay ? ;)
Several years now I think...
Aliki is something completely different (but you use to it measure
latency as well).
--
FA
Follie! Follie! Delirio vano è questo !
8:09 p.m.
New subject: jdelay
Fons Adriaensen wrote:
I missed the start of this thread, so I don't know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
yes, just measuring latency, If I can get more info it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass..
i still can't get rid of the '??' or get a proper absolute value. tried
two sound-cards, two different speakers + one headphone and 3 different
Mics.. (damn it's the cable, just kidding) - all with the same result.
If i just "loop" back jdelay internally it reports jack_buffsize
correctly.- If i watch the signals with `meterbridge -tsco` I can get
the mic to "looks the same" as jdelay's output, but jdelay already
recognizes much lower signals..
how do I debug the issue? running jack -r48000 -n 2 and then jdelay
jack_bufsize: 64
63250.894 frames ?? Inv
63250.897 frames ??
63250.897 frames ?? Inv
jack bufsize: 128
63378.825 frames ??
63378.833 frames ?? Inv
63378.833 frames ??
jack bufsize: 256
63635.066 frames ?? Inv
63635.066 frames ??
jack bufsize: 512
64146.942 frames ?? Inv
64146.942 frames ??
64146.920 frames ?? Inv
jack bufsize: 1024
65218.893 frames ??
65218.894 frames ?? Inv
65218.890 frames ??
jack bufsize 2048:
1874.796 frames ?? Inv
1874.796 frames ??
1874.801 frames ?? Inv
jack bufsize 4096:
6018.986 frames ?? Inv
6019.020 frames ??
6019.035 frames ?? Inv
I guess the last two just wrap around at 65536..- it can't be a stupid
compiler flag, can it? - I always get an alternating Inv, no-Inv
pattern. well not always but >90%
robin
9:05 p.m.
New subject: jdelay
On Wed, Apr 11, 2007 at 12:09:03AM +0200, Robin Gareus wrote:
Fons Adriaensen wrote:
Why use speakers, headphones or mics ? Just use a cable !! Things should
work then....
--
FA
Follie! Follie! Delirio vano è questo !
I missed the start of this thread, so I don't know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
yes, just measuring latency, If I can get more info it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass.. 
9:21 p.m.
New subject: jdelay
Fons Adriaensen wrote:
On Wed, Apr 11, 2007 at 12:09:03AM +0200, Robin Gareus
wrote:
hi fons, if i understand you, connecting line in (or mic in) with line out?
i connected now mic in with the line out and than in qjack i connected
alsa-pcm to jdelay input, and jdelay output to alsa-playback.
i get this values:
....
1055.521 ??
1055.521 ??
1055.520 ??
1055.519 ??
....
what means that?
jack is running here with 48k, 512/4 frames/buffer.
cheers,
doc
Fons Adriaensen wrote:
Why use speakers, headphones or mics ? Just use a cable !! Things should
work then....
I missed the start of this thread, so I don't
know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
yes, just measuring latency, If I can get more info it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass..
9:55 p.m.
New subject: jdelay
Dragan Noveski wrote:
Fons Adriaensen wrote:
Hi dragan. let me answer for Fons..
On Wed, Apr 11, 2007 at 12:09:03AM +0200, Robin
Gareus wrote:
hi fons, if i understand you, connecting line in (or mic in) with line out?
Fons Adriaensen wrote:
Why use speakers, headphones or mics ? Just use a cable !! Things should
work then....
I missed the start of this thread, so I don't
know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
yes, just measuring latency, If I can get more info it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass..
i connected now mic in with the line out and than in
qjack i connected
alsa-pcm to jdelay input, and jdelay output to alsa-playback.
i get this values:
....
1055.521 ??
1055.521 ??
1055.520 ??
1055.519 ??
....
what means that?
jack is running here with 48k, 512/4 frames/buffer.
the "??" mean that there are possible errors. check your volume level.
And it means that a complete audio cycle (in->process->out) takes
1055/48000 = 21 [ms].
robin
10:09 p.m.
New subject: jdelay
Robin Gareus wrote:
Dragan Noveski wrote:
exactly, i had to pretty turn up alsamixer!
Fons Adriaensen wrote:
Hi dragan. let me answer for Fons..
On Wed, Apr 11, 2007 at 12:09:03AM +0200, Robin
Gareus wrote:
hi fons, if i understand you, connecting line in (or mic in) with line
out?
Fons Adriaensen wrote:
> I missed the start of this thread, so I don't know what exactly you
> want to do... If it's measuring the latency of you soundcard, just
> cocnnect line out to line in !
>
>
yes, just measuring latency, If I can get more info it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass..
Why use speakers, headphones or mics ? Just use a cable !! Things should
work then....
i connected now mic in with the line out and than
in qjack i connected
alsa-pcm to jdelay input, and jdelay output to alsa-playback.
i get this values:
....
1055.521 ??
1055.521 ??
1055.520 ??
1055.519 ??
....
what means that?
jack is running here with 48k, 512/4 frames/buffer.
the "??" mean that there are possible errors. check your volume level.
And it means that a complete audio cycle
(in->process->out) takes
1055/48000 = 21 [ms].
ok, that is the onboard ac97, but i think that i got it.
cheers,
doc
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
11 Apr
11 Apr
8:30 a.m.
New subject: jdelay
On Wed, Apr 11, 2007 at 01:24:23AM +0200, Dragan Noveski wrote:
i connected now mic in with the line out and than in
qjack i connected
alsa-pcm to jdelay input, and jdelay output to alsa-playback.
i get this values:
....
1055.521 ??
1055.521 ??
1055.520 ??
1055.519 ??
Bad signal, which is normal if you connect line out to mic in, as
this overloads the mic input. You need either line out to line in,
or attenuate the line out signal to a level compatible with a mic
input.
--
FA
Follie! Follie! Delirio vano è questo !
10 Apr
10 Apr
9:44 p.m.
New subject: jdelay
Fons Adriaensen wrote:
On Wed, Apr 11, 2007 at 12:09:03AM +0200, Robin Gareus
wrote:
indeed ;) so -p64 -n2 -r 48000 on a 2.6.21-rt via USB yields a total
round trip latency of
376.759 frames
376.759 frames
376.760 frames
376.760 frames
376.759 frames
<8ms. Great!
but it's not really fun w/o a PA. ..I'm just measuring my stereo in the
living-room with aliki.. thanks for these great tools!
BTW. would it be unreasonable to "fix" jdelay to work with an amp&mic ?
Does the phase-measurement depend on electrical characteristics that get
"blurred" in mid-air? - Is there documentation for the algorithm used in
jdelay ?
Fons Adriaensen wrote:
Why use speakers, headphones or mics ? Just use a cable !! Things should
work then.... I missed the start of this thread, so I don't
know what exactly you
want to do... If it's measuring the latency of you soundcard, just
cocnnect line out to line in !
yes, just measuring latency, If I can get more info
it does not hurt,
though.. - I just connected a mic to jdelay and jdelay's out to a mono
quaker, though now I do have a 3-way speaker but jdelay does not use the
bass..
11 Apr
11 Apr
9:22 a.m.
New subject: jdelay
On Wed, Apr 11, 2007 at 01:44:29AM +0200, Robin Gareus wrote:
BTW. would it be unreasonable to "fix"
jdelay to work with an amp&mic ?
It will work via speaker an mic if both are linear phase (very unlikely
for speaker) and there are no significant reflections (echos) in the signal.
It can't be 'fixed' to work in other conditions - you need something
different. But jdelay is meant to measure sound card latency and not
delays in arbitrary channels.
Does the phase-measurement depend on electrical
characteristics that get
"blurred" in mid-air? - Is there documentation for the algorithm used in
jdelay ?
That will be difficult to find. The algo used is one developed some 40
years ago - and still used today - to measure the round-trip delay (and
hence distance) between a satellite and a ground station.
It requires a transmission channel with a linear phase characteristic
(same delay at all frequencies). This is easy to have on a space link.
On the other hand it can be made to work with very weak signals and
lots of noise, and with delays that are not constant but a function of
time. The equipment I designed while at Alcatel will operate reliably
with an input S/N ratio of -40 dB (yes, _minus_ forty) and will provide
an accuracy of a few centimeters (depending on how long you measure).
The algo uses a number of tones with frequencies F0, F1, F2, ...
and measures the phase difference between input and output for each
of them. Let P0, P1, P2, ... be those measured phases, expressed in
_cycles_. Let D (in seconds) be the delay we try to measure, and let
{x}, 0 <= {x} < 1 be the fractional part of x, i.e. x - floor(x).
The algo calculates V = D * F0, the delay expessed in cycles of F0.
Clearly we will have Pi = { D * Fi } for all i.
V = P0
This is the first estimate. The accuracy depends only on how good
the phase measurement is done, but it is of course ambiguous if the
delay can be more than one cycle.
The other tones will be used to resolve this ambiguity. We select
F1 so that
gcd (F0, F1) = F1 / 8.
Now consider the value N1 = 8 * P1 - P0. This will be an integer
in the range 0 to 7, plus some fraction due to meassurement error.
So we set
V = V + round (N1)
If the delay can be longer than 8 cycles of F0 then this is still
ambiguous. We select F2 so that
gcd (F0, F2) = F1 / 64.
Now consider N2 = 8 * P2 - P1. Again this will be an integer in
the range 0...7 plus some measurement error. So we set
V = V + 8 * round (N2)
We now have a measurement range of 64 cycles of F0. The other
tones are used in the same way to multiply this range by 8 for
each tone used. until the ambiguity-free range is large enough.
In jdelay F0 is Fsample / 8. The '??' are printed when the distance
between Ni and the nearest integer is more than 0.2, which indicates
that the signal is not reliable.
--
FA
Follie! Follie! Delirio vano è questo !
10:40 a.m.
New subject: jdelay
thanks, this is great! and with a morning-coffee all those hypot and
atan2 begin to look familiar... but i'm struggling to re-engineer this
for() {atan2 } loop back into an integral ;) - I need to carefully read
thru your post, probably not today..
Fons Adriaensen wrote:
Fons Adriaensen wrote:
On Wed, Apr 11, 2007 at 01:44:29AM +0200, Robin Gareus
wrote:
not that it had any straight forward audio apps. I was amazed how much I
could do in just 5 minutes! -
using jdelay as black-box that produces numbers. i can report success to
use it to measure distances down to cm accuracy. between a headphone and
mic. walking around in a room.
the current implementation is obviously not tailored for that, but this
old satellite-idea seems to be versatile... - Do you know who "invented"
it ?
robin
(sorry for top-posting; seemed appropriate here:)
BTW. would it be unreasonable to "fix"
jdelay to work with an amp&mic ?
It will work via speaker an mic if both are linear phase (very unlikely
for speaker) and there are no significant reflections (echos) in the signal.
It can't be 'fixed' to work in other conditions - you need something
different. But jdelay is meant to measure sound card latency and not
delays in arbitrary channels.
Does the
phase-measurement depend on electrical characteristics that get
"blurred" in mid-air? - Is there documentation for the algorithm used in
jdelay ?
That will be difficult to find. The algo used is one developed some 40
years ago - and still used today - to measure the round-trip delay (and
hence distance) between a satellite and a ground station.
It requires a transmission channel with a linear phase characteristic
(same delay at all frequencies). This is easy to have on a space link.
On the other hand it can be made to work with very weak signals and
lots of noise, and with delays that are not constant but a function of
time. The equipment I designed while at Alcatel will operate reliably
with an input S/N ratio of -40 dB (yes, _minus_ forty) and will provide
an accuracy of a few centimeters (depending on how long you measure).
The algo uses a number of tones with frequencies F0, F1, F2, ...
and measures the phase difference between input and output for each
of them. Let P0, P1, P2, ... be those measured phases, expressed in
_cycles_. Let D (in seconds) be the delay we try to measure, and let
{x}, 0 <= {x} < 1 be the fractional part of x, i.e. x - floor(x).
The algo calculates V = D * F0, the delay expessed in cycles of F0.
Clearly we will have Pi = { D * Fi } for all i.
V = P0
This is the first estimate. The accuracy depends only on how good
the phase measurement is done, but it is of course ambiguous if the
delay can be more than one cycle.
The other tones will be used to resolve this ambiguity. We select
F1 so that
gcd (F0, F1) = F1 / 8.
Now consider the value N1 = 8 * P1 - P0. This will be an integer
in the range 0 to 7, plus some fraction due to meassurement error.
So we set
V = V + round (N1)
If the delay can be longer than 8 cycles of F0 then this is still
ambiguous. We select F2 so that
gcd (F0, F2) = F1 / 64.
Now consider N2 = 8 * P2 - P1. Again this will be an integer in
the range 0...7 plus some measurement error. So we set
V = V + 8 * round (N2)
We now have a measurement range of 64 cycles of F0. The other
tones are used in the same way to multiply this range by 8 for
each tone used. until the ambiguity-free range is large enough.
In jdelay F0 is Fsample / 8. The '??' are printed when the distance
between Ni and the nearest integer is more than 0.2, which indicates
that the signal is not reliable.
On Wed, Apr 11, 2007 at 01:27:27PM +0200, Fons
Adriaensen wrote:
some typos...
gcd (F0, F1) = F1 / 8.
gcd (F0, F2) = F1 / 64.
should be:
gcd (F0, F1) = F0 / 8.
gcd (F0, F2) = F0 / 64.
10 Apr
10 Apr
10:18 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Dmitry Baikov wrote:
On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
One thing is of course that you should check that your bridge's
interrupt isn't shared either.
PCMCIA is ok, but not great for low latency.
(adds one extra interface
between PCI bus & sound-card). - the cheap solution is to get a PCMCIA
card for your hard-disk - instead of using the built-in firewire for the
disk. - maybe you want to do that anyway. use the built-in firewire to
an external audio-device and the PCMCIA for storage.
Quite the opposite.
PCMCIA is great for latency. That "extra" PCI bridge does NOT affect
audio latency. Firewire latencies are bigger than PCI/PCMCIA and will
always be. Ask
Pieter Palmers for details.
Correct. The FireWire host controller is a PCI card,
meaning that it has
the same latency limitations as a PCI soundcard. The latency of the
FireWire bus itself is added to this lower limit.
Let's say that if you can achieve a certain latency number on a certain
configuration with a prefect FireWire setup, you will always be able to
achieve a lower latency on the same system with a perfect PCI setup.
That being said, I don't think this is an issue. If we address the
FireWire host controller in the same way as we address the PCI soundcard
(i.e. DMA double buffering), it won't introduce any extra latency. The
extra latency that occurs, is due to the buffering on the device.
Therefore, with respect to latency, there is not really a difference
between FireWire and ADAT or MADI: It depends on the buffering on the
interface you hook up to it. Basically firewire can give the same
performance as RME+MADI, Delta+ADAT, ...
There is one problem with this: currently we can't adress the FireWire
host controller in this manner, meaning that we are limited in the
performance. It is being solved in the new juju firewire stack.
So if you are for low latency, PCI/PCMCIA is unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME
MultifaceII.
Ask somebody to jdelay their Firewire card.
Please don't :). The current system
is far from 'ideal', and would
certainly give a wrong impression on the capabilities of the FireWire
technology.
Results for a first generation FireWire device:
http://freebob.sourceforge.net/index.php/ESI_Quatafire_Latency
At 48k it comes down to the fact that the device + the windows 1394
stack together limit the roundtrip latency to around 250 frames. FreeBoB
has a similar latency lower limit. Note that the audio buffers should be
added to this, making the actual number around 320 frames.
The newer FireWire devices (based upon DM1500 or certainly DICE) will
exhibit much lower latencies. I don't have figures on that yet, I'll try
and see if I can get some... I expect something like 50-100 frames of
extra latency, for a total of around 150 frames. This is quite
comparable to the PCI cards.
Pieter
10:48 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Pieter Palmers <pieterp(a)joow.be> wrote:
The newer FireWire devices (based upon DM1500 or
certainly DICE) will
exhibit much lower latencies. I don't have figures on that yet, I'll try
and see if I can get some... I expect something like 50-100 frames of
extra latency, for a total of around 150 frames. This is quite
comparable to the PCI cards.
Yay!!! This is MegaCool!
When/if it become true, I'll switch to Firewire, immediately :)
Pieter, may be I should join your team to speed up the process?
My (ex) M-Audio Delta66 (PCI) gave 188 frames at 64x2(a)44.1
MultifaceII (PCMCIA) gives about 200 frames at the same settings (do
not remember the exact number).
Dmitry.
11:08 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Dmitry Baikov wrote:
On 4/10/07, Pieter Palmers <pieterp(a)joow.be>
wrote:
I would definitely
welcome you aboard! And it would certainly speed up
the process :).
The newer FireWire devices (based upon DM1500 or
certainly DICE) will
exhibit much lower latencies. I don't have figures on that yet, I'll try
and see if I can get some... I expect something like 50-100 frames of
extra latency, for a total of around 150 frames. This is quite
comparable to the PCI cards.
Yay!!! This is MegaCool!
When/if it become true, I'll switch to Firewire, immediately :)
Pieter, may be I should join your team to speed up the process? My (ex) M-Audio Delta66 (PCI) gave 188 frames at
64x2(a)44.1
MultifaceII (PCMCIA) gives about 200 frames at the same settings (do
not remember the exact number).
Let's say that FireWire has the potential to be very comparable to PCI.
Pieter
1:33 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Dmitry Baikov <dsbaikov(a)gmail.com> wrote:
PCMCIA is great for latency. That "extra"
PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details.
So if you are for low latency, PCI/PCMCIA is unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME MultifaceII.
Ask somebody to jdelay their Firewire card.
Is anybody using a firewire card through a PCMCIA adpter? I hesitate
to use a firewire card because I want something that's bus-powered,
but this laptop only has a 4-pin firewire. I'm leaning perhaps to the
Edirol UA-25, but the presonus Firebox is 4in/6out instead of 2in/2out
(Analog) so if it's not a problem to run it through a PCMCIA firewire
card then I think that's what I would go with. Both seem to have
decent Linux support, as far as I can tell.
-spencer
3:19 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Spencer Russell wrote:
On 4/10/07, Dmitry Baikov <dsbaikov(a)gmail.com>
wrote:
I use both onboard 1394 and Cardbus 1394 for my tests, and I've never
seen a difference. But I have to admit that I haven't been doing latency
comparisons between the two that would survive scientific proofing.
Note that there might be exceptions, but:
PCMCIA or Cardbus adapters are also unable to provide bus power,
notwithstanding the fact that they do have 6-pin adapters. The
PCMCIA/cardbus bus doesn't provide the power needed for the FireWire
bus, so these adapters can't provide it.
Pieter
PCMCIA is great for latency. That
"extra" PCI bridge does NOT affect
audio latency.
Firewire latencies are bigger than PCI/PCMCIA and will always be. Ask
Pieter Palmers for details.
So if you are for low latency, PCI/PCMCIA is unbeatable.
If you want numbers, I can provide them for Echo Indigo IO and RME
MultifaceII.
Ask somebody to jdelay their Firewire card.
Is anybody using a firewire card through a PCMCIA adpter? I hesitate
to use a firewire card because I want something that's bus-powered,
but this laptop only has a 4-pin firewire. I'm leaning perhaps to the
Edirol UA-25, but the presonus Firebox is 4in/6out instead of 2in/2out
(Analog) so if it's not a problem to run it through a PCMCIA firewire
card then I think that's what I would go with. Both seem to have
decent Linux support, as far as I can tell.
4:11 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Pieter Palmers <pieterp(a)joow.be> wrote:
Spencer Russell wrote:
Hrm, this is problematic. I'd just about settled down to the idea of
either the Presonus Firepod of the Edirol FA-66, but if there's no way
to get them portable power, I guess I'll have to stick with something
USB. I had a lot of trouble with a tascam US428 a couple years back,
so I'd like to stick with something that doesn't require so much
tweaking and a custom module (unless that's changed recently), so I
guess it's back to the search. I guess the Edirol UA-25 is still high
in the running.
spencer
Is anybody using a firewire card through a PCMCIA adpter? I hesitate
to use a firewire card because I want something that's bus-powered,
but this laptop only has a 4-pin firewire. I'm leaning perhaps to the...
Note that there might be exceptions, but:
PCMCIA or Cardbus adapters are also unable to provide bus power,
notwithstanding the fact that they do have 6-pin adapters. The
PCMCIA/cardbus bus doesn't provide the power needed for the FireWire
bus, so these adapters can't provide it.
8:04 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Spencer Russell wrote:
On 4/10/07, Pieter Palmers <pieterp(a)joow.be>
wrote:
> Spencer Russell wrote:
> >
> > Is anybody using a firewire card through a PCMCIA adpter? I hesitate
> > to use a firewire card because I want something that's bus-powered,
> > but this laptop only has a 4-pin firewire. I'm leaning perhaps to
> the...
>
>
> Note that there might be exceptions, but:
> PCMCIA or Cardbus adapters are also unable to provide bus power,
> notwithstanding the fact that they do have 6-pin adapters. The
> PCMCIA/cardbus bus doesn't provide the power needed for the FireWire
> bus, so these adapters can't provide it.
>
IIRC. PCMCIA devices may use max. 500mA. (*5V = 2.5W). and it's well
protected against drawing too much current from it. (at least compared
to USB.)
Hrm, this is problematic. I'd just about settled
down to the idea of
either the Presonus Firepod of the Edirol FA-66, but if there's no way
to get them portable power,
you could get or build an adapter. USB-power + 4pin 1394 to 6pin 1394.
9:54 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Robin Gareus <robin(a)gareus.org> wrote:
Spencer Russell wrote:
I thought about that, but according to [1], Firewire supplies 30V! Can
anyone confirm this? USB only provides 5V, so it would take more than
just an adapter to step up the voltage.
[1] http://articles.techrepublic.com.com/5102-6349-5826975.html
-spencer
Hrm, this is problematic. I'd just about
settled down to the idea of
either the Presonus Firepod of the Edirol FA-66, but if there's no way
to get them portable power,
you could get or build an adapter. USB-power + 4pin 1394 to 6pin 1394.
10:16 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Spencer Russell wrote:
On 4/10/07, Robin Gareus <robin(a)gareus.org>
wrote:
There are different kind of "power classes" for IEEE-1394.
1394 requires the devices to regulate their own voltage.
The minimum voltage is 8V! 9.25V recommended. it can be as high as 30V.
and should not exceed a current of 1.5A... - The PCI-firewire in my
desktop just forwards the 12 Volts from the ATX power supply.. -> bug
someone with a Mac & Voltmeter ;)
Many firewire devices will work just fine with +5V -
phantom-powered preamps might pose some kind of a problem..
#robin
Spencer Russell wrote:
I thought about that, but according to [1], Firewire supplies 30V! Can
anyone confirm this? USB only provides 5V, so it would take more than
just an adapter to step up the voltage. Hrm, this is problematic. I'd just about
settled down to the idea of
either the Presonus Firepod of the Edirol FA-66, but if there's no way
to get them portable power,
you could get or build an adapter. USB-power + 4pin 1394 to 6pin 1394.
18 Apr
18 Apr
4:46 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Robin Gareus wrote:
[snip]
As for Sound: I rarely use the SD-reader (sdhci:slot0
- BTW. unloading
the module saves power!) so I connect a USB UA-25 to either IRQ22 or
IRQ23. even if it's the only device on that bus I get rare xruns on 64
frames/period. but a robust setup with `jackd -R -P 70 -d alsa -d hw:1
-p 256 -r 48000` makes this Thinkpad a great machine for
stereo/binaural audio work and fun! - (recap: the Dell D820 seems
somewhat better suited for pro-audio, and a Vaio sz3 is similarly good,
but sony&linux requires a little more some devotion..)
I'm curious: where did you get information that the Dell D820 is better
suited? I'm wondering if there is some info available about the IRQ
mapping in the D820 which can help me make a decision whether to get the
Dell D820 or a Lenovo T60p.
Thanks,
/ken
thinkpad x60s:
CPU0 CPU1
0: 352029528 0 IO-APIC-edge timer
1: 1251013 0 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 65043220 0 IO-APIC-fasteoi acpi
12: 10126775 0 IO-APIC-edge i8042
20: 35583442 20485440 IO-APIC-fasteoi yenta,
i915@pci:0000:00:02.0, uhci_hcd:usb1
21: 200293604 250337407 IO-APIC-fasteoi ohci1394, ipw3945, HDA
Intel, uhci_hcd:usb2
22: 65491123 0 IO-APIC-fasteoi sdhci:slot0, uhci_hcd:usb3
23: 745166 1065462 IO-APIC-fasteoi ehci_hcd:usb5, uhci_hcd:usb4
218: 1670650 179 PCI-MSI-edge eth1
219: 810037 3174745 PCI-MSI-edge libata
NMI: 0 0
LOC: 107326912 241228138
ERR: 0
MIS: 0
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
4:49 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Wed, 2007-04-18 at 11:49 -0700, Ken Dawson wrote:
Robin Gareus wrote:
[snip]
This is from my D820
v2@mustis:~$ cat /proc/interrupts
CPU0 CPU1
0: 15528582 0 IO-APIC-edge timer
1: 41503 0 IO-APIC-edge i8042
8: 3 0 IO-APIC-edge rtc
9: 3 0 IO-APIC-level acpi
12: 402591 0 IO-APIC-edge i8042
14: 223652 0 IO-APIC-edge libata
15: 114216 0 IO-APIC-edge libata
50: 139 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2
58: 49353 0 IO-APIC-level uhci_hcd:usb3
66: 0 0 IO-APIC-level uhci_hcd:usb4
74: 0 0 IO-APIC-level uhci_hcd:usb5
82: 1 0 PCI-MSI eth2
90: 640094 0 PCI-MSI HDA Intel
169: 0 0 IO-APIC-level i915@pci:0000:00:02.0
177: 4260189 0 IO-APIC-level ipw3945
193: 10 0 IO-APIC-level ohci1394, yenta
NMI: 0 0
LOC: 15528366 15528365
ERR: 0
MIS: 0
Sampo
As for Sound: I rarely use the SD-reader
(sdhci:slot0 - BTW. unloading
the module saves power!) so I connect a USB UA-25 to either IRQ22 or
IRQ23. even if it's the only device on that bus I get rare xruns on 64
frames/period. but a robust setup with `jackd -R -P 70 -d alsa -d hw:1
-p 256 -r 48000` makes this Thinkpad a great machine for
stereo/binaural audio work and fun! - (recap: the Dell D820 seems
somewhat better suited for pro-audio, and a Vaio sz3 is similarly good,
but sony&linux requires a little more some devotion..)
I'm curious: where did you get information that the Dell D820 is better
suited? I'm wondering if there is some info available about the IRQ
mapping in the D820 which can help me make a decision whether to get the
Dell D820 or a Lenovo T60p.
5:15 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Sampo Savolainen wrote:
On Wed, 2007-04-18 at 11:49 -0700, Ken Dawson wrote:
Thanks for this. How do you like your D820 under Linux? I'm especially
interested in how well the graphics, wireless LAN, and ACPI support
work. Oh, and the audio.
/ken
Robin Gareus wrote:
[snip]
This is from my D820
v2@mustis:~$ cat /proc/interrupts
CPU0 CPU1
0: 15528582 0 IO-APIC-edge timer
1: 41503 0 IO-APIC-edge i8042
8: 3 0 IO-APIC-edge rtc
9: 3 0 IO-APIC-level acpi
12: 402591 0 IO-APIC-edge i8042
14: 223652 0 IO-APIC-edge libata
15: 114216 0 IO-APIC-edge libata
50: 139 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2
58: 49353 0 IO-APIC-level uhci_hcd:usb3
66: 0 0 IO-APIC-level uhci_hcd:usb4
74: 0 0 IO-APIC-level uhci_hcd:usb5
82: 1 0 PCI-MSI eth2
90: 640094 0 PCI-MSI HDA Intel
169: 0 0 IO-APIC-level i915@pci:0000:00:02.0
177: 4260189 0 IO-APIC-level ipw3945
193: 10 0 IO-APIC-level ohci1394, yenta
NMI: 0 0
LOC: 15528366 15528365
ERR: 0
MIS: 0
Sampo
As for Sound: I rarely use the SD-reader
(sdhci:slot0 - BTW. unloading
the module saves power!) so I connect a USB UA-25 to either IRQ22 or
IRQ23. even if it's the only device on that bus I get rare xruns on 64
frames/period. but a robust setup with `jackd -R -P 70 -d alsa -d hw:1
-p 256 -r 48000` makes this Thinkpad a great machine for
stereo/binaural audio work and fun! - (recap: the Dell D820 seems
somewhat better suited for pro-audio, and a Vaio sz3 is similarly good,
but sony&linux requires a little more some devotion..)
I'm curious: where
did you get information that the Dell D820 is better
suited? I'm wondering if there is some info available about the IRQ
mapping in the D820 which can help me make a decision whether to get the
Dell D820 or a Lenovo T60p.
6:08 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Wed, 2007-04-18 at 12:17 -0700, Ken Dawson wrote:
Thanks for this. How do you like your D820 under
Linux? I'm especially
interested in how well the graphics, wireless LAN, and ACPI support
work. Oh, and the audio.
I've got intel graphics. Works great after 915resolution is installed
(it's needed for the bios hack to access teh 1920x1200 video mode)
The dell is sold with the intel 3945d chip or the "dell
wireless" (broadcom something). Needless to say, i got it with the intel
chip. Works great.
ACPI? I've never had to worry about that. Fans etc. work well. I'm not
sure if it's related with ACPI but an interesting tidbit: if the PSU
cord is connected poorly long enough, the bios decides it can't be sure
it's getting enough power and forces the cpu frequency scaling to set
the max scaling freq to min freq. So the cpu gets stuck at the lowest
speed. This can be fixed by removing the PSU cord for a while,
re-inserting it. (you might need to fiddle
with /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq
afterwards)
Audio? A few hacks needed.
1) You need to set the Capture element in the mixer to record,
otherwise the driver will not return any samples when recording.
2) At least with my current alsa version (1.0.13rc2) needs
position_fix=1 as a parameter for the snd-hda-intel driver
After those fixes it works well. haven't tried spdif though as I have no
dock. I use an RME multiface + pcmcia card for real work and it works
just great. I havent' attempted extreme latencies as I have no need for
such.
All in all? Very little hassle for a very new machine. It's extremely
fast, relatively quiet, good battery life, the screen is wonderful
albeit not very bright.
I'm happy with it.
Sampo
PS. One hint. If you decide to get one: call them and ask for an offer,
don't get it at list price!
6:31 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Sampo,
I appreciate your reply.
Sampo Savolainen wrote:
On Wed, 2007-04-18 at 12:17 -0700, Ken Dawson wrote:
I ask because I have a system using an ASUS M2N32-SLI (AMD 64bit)
motherboard, and it will not even consider booting unless I specify
-acpi=off to the kernel. I wouldn't want to voluntarily encounter this
condition again.
Thanks for this. How do you like your D820 under
Linux? I'm especially
interested in how well the graphics, wireless LAN, and ACPI support
work. Oh, and the audio.
I've got intel graphics. Works great after 915resolution is installed
(it's needed for the bios hack to access teh 1920x1200 video mode)
The dell is sold with the intel 3945d chip or the "dell
wireless" (broadcom something). Needless to say, i got it with the intel
chip. Works great.
ACPI? I've never had to worry about that. Fans etc. work well. I'm not
sure if it's related with ACPI but an interesting tidbit: if the PSU
cord is connected poorly long enough, the bios decides it can't be sure
it's getting enough power and forces the cpu frequency scaling to set
the max scaling freq to min freq. So the cpu gets stuck at the lowest
speed. This can be fixed by removing the PSU cord for a while,
re-inserting it. (you might need to fiddle
with /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq
afterwards)
Audio? A few hacks needed.
1) You need to set the Capture element in the mixer to record,
otherwise the driver will not return any samples when recording.
2) At least with my current alsa version (1.0.13rc2) needs
position_fix=1 as a parameter for the snd-hda-intel driver
After those fixes it works well. haven't tried spdif though as I have no
dock. I use an RME multiface + pcmcia card for real work and it works
just great. I havent' attempted extreme latencies as I have no need for
such.
All in all? Very little hassle for a very new machine. It's extremely
fast, relatively quiet, good battery life, the screen is wonderful
albeit not very bright.
I'm happy with it.
Sampo
PS. One hint. If you decide to get one: call them and ask for an offer,
don't get it at list price!
This I don't understand. Last time I bought a Dell laptop, it was
purely through the web-page, and totally cut-and-dried. How do you go
about haggling with them? I've never found their phone talent to be (1)
easily reached or (2) really engaged when I did reach them, sales or
support.
/ken
6:58 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/18/07, Ken Dawson <dawsonwu(a)rahul.net> wrote:
I ask because I have a system using an ASUS M2N32-SLI
(AMD 64bit)
motherboard, and it will not even consider booting unless I specify
-acpi=off to the kernel. I wouldn't want to voluntarily encounter this
condition again.
Report it to http://bugzilla.kernel.org.
Lee
19 Apr
19 Apr
7:49 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Sampo Savolainen wrote:
On Wed, 2007-04-18 at 12:17 -0700, Ken Dawson wrote:
I have the NVidia card and it works out of the box.
Thanks for this. How do you like your D820 under
Linux? I'm especially
interested in how well the graphics, wireless LAN, and ACPI support
work. Oh, and the audio.
I've got intel graphics. Works great after 915resolution is installed
(it's needed for the bios hack to access teh 1920x1200 video mode)
The dell is sold with the intel 3945d chip or the
"dell
wireless" (broadcom something). Needless to say, i got it with the intel
chip. Works great.
Same here.
ACPI? I've never had to worry about that. Fans etc. work well. I'm not
sure if it's related with ACPI but an interesting tidbit: if the PSU
cord is connected poorly long enough, the bios decides it can't be sure
it's getting enough power and forces the cpu frequency scaling to set
the max scaling freq to min freq. So the cpu gets stuck at the lowest
speed. This can be fixed by removing the PSU cord for a while,
re-inserting it. (you might need to fiddle
with /sys/devices/system/cpu/cpu[01]/cpufreq/scaling_max_freq
afterwards)
Audio? A few hacks needed.
1) You need to set the Capture element in the mixer to record,
otherwise the driver will not return any samples when recording.
2) At least with my current alsa version (1.0.13rc2) needs
position_fix=1 as a parameter for the snd-hda-intel driver
After those fixes it works well. haven't tried spdif though as I have no
dock. I use an RME multiface + pcmcia card for real work and it works
just great. I havent' attempted extreme latencies as I have no need for
such.
I'll be getting a dock soon, I'll update on that later.
All in all? Very little hassle for a very new machine. It's extremely
fast, relatively quiet, good battery life, the screen is wonderful
albeit not very bright.
I'm happy with it.
Me too.
PS. One hint. If you decide to get one: call them and ask for an offer,
don't get it at list price!
Getting an offer saved me 20% compared to the website price.
Pieter
7:46 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Ken Dawson wrote:
Robin Gareus wrote:
[snip]
This is for my D820 and stock ubuntu feisty kernel.
CPU0 CPU1
0: 1020534 0 IO-APIC-edge timer
1: 1854 0 IO-APIC-edge i8042
8: 23 0 IO-APIC-edge rtc
9: 5 0 IO-APIC-fasteoi acpi
12: 115 0 IO-APIC-edge i8042
14: 38534 0 IO-APIC-edge libata
15: 28846 0 IO-APIC-edge libata
16: 220577 0 IO-APIC-fasteoi nvidia
17: 2106 102830 IO-APIC-fasteoi ipw3945
18: 145 0 IO-APIC-fasteoi eth0
19: 10 0 IO-APIC-fasteoi ohci1394, yenta
20: 405137 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
21: 35138 0 IO-APIC-fasteoi uhci_hcd:usb2, HDA Intel
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
23: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
NMI: 0 0
LOC: 1020404 1020403
ERR: 0
MIS: 0
Pieter
As for Sound: I rarely use the SD-reader
(sdhci:slot0 - BTW. unloading
the module saves power!) so I connect a USB UA-25 to either IRQ22 or
IRQ23. even if it's the only device on that bus I get rare xruns on 64
frames/period. but a robust setup with `jackd -R -P 70 -d alsa -d hw:1
-p 256 -r 48000` makes this Thinkpad a great machine for
stereo/binaural audio work and fun! - (recap: the Dell D820 seems
somewhat better suited for pro-audio, and a Vaio sz3 is similarly good,
but sony&linux requires a little more some devotion..)
I'm curious: where did you get information that the Dell D820 is better
suited? I'm wondering if there is some info available about the IRQ
mapping in the D820 which can help me make a decision whether to get the
Dell D820 or a Lenovo T60p.
5:52 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Robin Gareus wrote:
[snip]
>
> thinkpad x60s:
>
> CPU0 CPU1
> 0: 352029528 0 IO-APIC-edge timer
> 1: 1251013 0 IO-APIC-edge i8042
> 8: 0 0 IO-APIC-edge rtc
> 9: 65043220 0 IO-APIC-fasteoi acpi
> 12: 10126775 0 IO-APIC-edge i8042
> 20: 35583442 20485440 IO-APIC-fasteoi yenta,
> i915@pci:0000:00:02.0, uhci_hcd:usb1
> 21: 200293604 250337407 IO-APIC-fasteoi ohci1394, ipw3945, HDA
> Intel, uhci_hcd:usb2
> 22: 65491123 0 IO-APIC-fasteoi sdhci:slot0, uhci_hcd:usb3
> 23: 745166 1065462 IO-APIC-fasteoi ehci_hcd:usb5,
> uhci_hcd:usb4
> 218: 1670650 179 PCI-MSI-edge eth1
> 219: 810037 3174745 PCI-MSI-edge libata
> NMI: 0 0
> LOC: 107326912 241228138
> ERR: 0
> MIS: 0
Hi again,
The other question I have (as I am preparing to make a fairly pricey
decision) is whether anyone could provide this type of information for
the Lenovo t60p, or t60.
Thanks,
/ken
7:46 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 2007-04-19T12:55:00-0700, Ken Dawson wrote:
The other question I have (as I am preparing to make a
fairly pricey
decision) is whether anyone could provide this type of information for
the Lenovo t60p, or t60.
z61p:
allan_wind@viento:~$ cat /proc/interrupts
CPU0 CPU1
0: 2853045399 0 XT-PIC-XT timer
1: 2072829 0 XT-PIC-XT i8042
2: 0 0 XT-PIC-XT cascade
9: 28354520 0 XT-PIC-XT acpi
11: 73153 0 XT-PIC-XT ehci_hcd:usb1, yenta, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5, ohci1394, HDA Intel
12: 51346798 0 XT-PIC-XT i8042
14: 31081927 0 XT-PIC-XT libata
15: 0 0 XT-PIC-XT libata
313: 14181079 381 PCI-MSI-edge eth0
314: 2266196 375 PCI-MSI-edge libata
NMI: 130142 48808
LOC: 2853063066 2853112560
ERR: 12
I have not tried to do anything with interrupt 11 (i.e. bios tweaks or module
options).
/Allan
8:12 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Toshiba Satellite A100 (Sampo, Dells here are way too expensive and rare).
CPU0 CPU1
0: 4006308 0 IO-APIC-edge timer
1: 16408 0 IO-APIC-edge i8042
8: 2453050 0 IO-APIC-edge rtc
9: 10758 0 IO-APIC-fasteoi acpi
12: 146539 0 IO-APIC-edge i8042
14: 85257 0 IO-APIC-edge libata
15: 26553 0 IO-APIC-edge libata
16: 232572 0 IO-APIC-fasteoi uhci_hcd:usb5, nvidia
17: 100000 0 IO-APIC-fasteoi ohci1394
18: 2866580 0 IO-APIC-fasteoi tifm_7xx1, yenta,
uhci_hcd:usb4, ipw3945, Indigo IO, sdhci:slot0
19: 4897 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 1946 0 IO-APIC-fasteoi eth0
22: 161 0 IO-APIC-fasteoi HDA Intel
23: 26 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 69 33
LOC: 4006187 4006108
ERR: 0
Strangely enough, here firewire controller is on the separate line
(this is rare).
Interrupt 18 (with yenta) is very busy, but seems it does not cause
any problems.
The main problem is ACPI.
When it works behind the scenes, it causes jackd to click:
delay of 2202.000 usecs exceeds estimated spare time of 1320.000; restart ...
The only way to workaround this is to boot with acpi=off. The thing
becomes stable as a rock, but looses battery/frequency/temperature
control. Which is a pity.
Dmitry.
20 Apr
20 Apr
1:20 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
Best
Allan Wind wrote:
On 2007-04-19T12:55:00-0700, Ken Dawson wrote:
The other question I have (as I am preparing to
make a fairly pricey
decision) is whether anyone could provide this type of information for
the Lenovo t60p, or t60.
z61p:
allan_wind@viento:~$ cat /proc/interrupts
CPU0 CPU1
0: 2853045399 0 XT-PIC-XT timer
1: 2072829 0 XT-PIC-XT i8042
2: 0 0 XT-PIC-XT cascade
9: 28354520 0 XT-PIC-XT acpi
11: 73153 0 XT-PIC-XT ehci_hcd:usb1, yenta, uhci_hcd:usb2,
uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5, ohci1394, HDA Intel
12: 51346798 0 XT-PIC-XT i8042
14: 31081927 0 XT-PIC-XT libata
15: 0 0 XT-PIC-XT libata
313: 14181079 381 PCI-MSI-edge eth0
314: 2266196 375 PCI-MSI-edge libata
NMI: 130142 48808
LOC: 2853063066 2853112560
ERR: 12
I have not tried to do anything with interrupt 11 (i.e. bios tweaks or module
options).
/Allan
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
1:43 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
mea wrote:
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
yes, in the worst case you just need to reboot and re-set them..
(hihi; if you dual boot: windows might find some new devices after
flipping those around; prepare to jockey (not mount) the driver CD/DVD)
ABCD usually correspond do the PCI irq wires . aehm striplines or
signals. ;) - some bios allow to choose "[voltage]level" or "edge"
IRQ
detection. - not sure if and how that affects rt-linux. i use edge
detection.
assiging each letter to a different IRQ number and checking the output
of /proc/interrupts seems like a good idea. try IRQ 3,5,9,11 for example.
you might still be unlucky: the firewire device might share the "wire"
with some other [inconvenient] device(s).
robin
2:02 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Robin Gareus wrote:
mea wrote:
If I recall this correctly, level detection is better because it allows
for shared interrupts. The interrupt line is pulled high by any device
that wants to generate an interrupt. As long as the interrupt line is
high, the CPU should execute an interrupt handler. This means that if
device A and device B both are connected to the same interrupt line, and
both generate an interrupt simultanously they both pull the interrupt
line up. The CPU detects this and starts the interrupt service routine
that handles either A or B. The device that was handled (e.g. A) stops
pulling the line up, which normally exits the interrupt state. But since
in this case there is another device with an unhandled interrupt (i.e.
B), the doesn't go up and the CPU does another round of interrupt handling.
But it has been a long time since I've been into this...
Pieter
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
yes, in the worst case you just need to reboot and re-set them..
(hihi; if you dual boot: windows might find some new devices after
flipping those around; prepare to jockey (not mount) the driver CD/DVD)
ABCD usually correspond do the PCI irq wires . aehm striplines or
signals. ;) - some bios allow to choose "[voltage]level" or "edge"
IRQ
detection. - not sure if and how that affects rt-linux. i use edge
detection.
assiging each letter to a different IRQ number and checking the output
of /proc/interrupts seems like a good idea. try IRQ 3,5,9,11 for example.
you might still be unlucky: the firewire device might share the "wire"
with some other [inconvenient] device(s).
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
2:28 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Thanks for the quick answers,
I will give it a another try next week or so, when I have a bit more
time, last time I tried to set it up it took a week and no success, but
maybe this time ;)
@Pieter Palmers>> the chipset is Texas Insts., not Ricoh.
Thanks again
Best
Martin
Pieter Palmers wrote:
Robin Gareus wrote:
mea wrote:
If I recall this correctly, level detection is better because it allows
for shared interrupts. The interrupt line is pulled high by any device
that wants to generate an interrupt. As long as the interrupt line is
high, the CPU should execute an interrupt handler. This means that if
device A and device B both are connected to the same interrupt line, and
both generate an interrupt simultanously they both pull the interrupt
line up. The CPU detects this and starts the interrupt service routine
that handles either A or B. The device that was handled (e.g. A) stops
pulling the line up, which normally exits the interrupt state. But since
in this case there is another device with an unhandled interrupt (i.e.
B), the doesn't go up and the CPU does another round of interrupt handling.
But it has been a long time since I've been into this...
Pieter
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
yes, in the worst case you just need to reboot and re-set them..
(hihi; if you dual boot: windows might find some new devices after
flipping those around; prepare to jockey (not mount) the driver CD/DVD)
ABCD usually correspond do the PCI irq wires . aehm striplines or
signals. ;) - some bios allow to choose "[voltage]level" or "edge"
IRQ
detection. - not sure if and how that affects rt-linux. i use edge
detection.
assiging each letter to a different IRQ number and checking the output
of /proc/interrupts seems like a good idea. try IRQ 3,5,9,11 for
example.
you might still be unlucky: the firewire device might share the "wire"
with some other [inconvenient] device(s).
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
2:40 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Robin Gareus wrote:
mea wrote:
hi robin, this is a really nice advice!
after tweaking for some minutes around and rebooting i got this result now:
nowhiskey@murija2:~$ cat /proc/interrupts
CPU0
0: 1014092 XT-PIC-XT timer
1: 1101 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
8: 1 XT-PIC-XT rtc
9: 32 XT-PIC-XT acpi, uhci_hcd:usb4
10: 141435 XT-PIC-XT ehci_hcd:usb1, ipw2200,
uhci_hcd:usb3, Intel 82801DB-ICH4
11: 1 XT-PIC-XT yenta, uhci_hcd:usb2
12: 32709 XT-PIC-XT i8042
14: 7164 XT-PIC-XT ide0
15: 11 XT-PIC-XT ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
nowhiskey@murija2:~$
since i am only interested in optimizing the yenta, where the multiface
is hanging, i think this is ok (there is nothing pluged into usb, when i
am doing real audio work here).
what do you peoples think about??
if that is ok, as a next, according to tappas.affenbande i coud do:
chrt -f -p 82 `pidof "IRQ 11"`
chrt -f -p 98 `pidof "IRQ 8"`
jackd is running at 70 (simply adjusted in qjackctl).
cheers,
doc
p.s. sorry for being off-topic, it really has not to do anything with
firewire here...
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
yes, in the worst case you just need to reboot and re-set them..
(hihi; if you dual boot: windows might find some new devices after
flipping those around; prepare to jockey (not mount) the driver CD/DVD)
ABCD usually correspond do the PCI irq wires . aehm striplines or
signals. ;) - some bios allow to choose "[voltage]level" or "edge"
IRQ
detection. - not sure if and how that affects rt-linux. i use edge
detection.
assiging each letter to a different IRQ number and checking the output
of /proc/interrupts seems like a good idea. try IRQ 3,5,9,11 for example.
you might still be unlucky: the firewire device might share the "wire"
with some other [inconvenient] device(s).
robin
1:51 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
mea wrote:
Hi,
Sorry to bump into the thread like this, but I have 3+ year old R40 and
I never managed to make it work with my firewire sound card under linux,
You should check whether your laptop has a Ricoh 1394 chipset. If it
does, you're out of luck. Ricoh chipsets are buggy in hardware, and
cannot be used for firewire audio interfaces. Thinkpads are known to use
these chipsets.
lspci | grep 1394
should give you an idea.
Pieter Palmers
I think mainly because of> cat /proc/interrupts
0: 6674809 XT-PIC timer
1: 24 XT-PIC i8042
2: 0 XT-PIC cascade
6: 3 XT-PIC floppy
8: 1 XT-PIC rtc
9: 48 XT-PIC acpi
11: 1744806 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2,
uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
radeon@pci:0000:01:00.0
12: 35 XT-PIC i8042
14: 27840 XT-PIC ide0
15: 20 XT-PIC ide1
NMI: 0
ERR: 0
As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
etc) all assigned to 11. Is it safe to try to change them?
Best
Allan Wind wrote:
On 2007-04-19T12:55:00-0700, Ken Dawson wrote:
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
The other question I have (as I am preparing to
make a fairly pricey
decision) is whether anyone could provide this type of information
for the Lenovo t60p, or t60.
z61p:
allan_wind@viento:~$ cat /proc/interrupts
CPU0 CPU1
0: 2853045399 0 XT-PIC-XT timer
1: 2072829 0 XT-PIC-XT i8042
2: 0 0 XT-PIC-XT cascade
9: 28354520 0 XT-PIC-XT acpi
11: 73153 0 XT-PIC-XT ehci_hcd:usb1, yenta,
uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5, ohci1394,
HDA Intel
12: 51346798 0 XT-PIC-XT i8042
14: 31081927 0 XT-PIC-XT libata
15: 0 0 XT-PIC-XT libata
313: 14181079 381 PCI-MSI-edge eth0
314: 2266196 375 PCI-MSI-edge libata
NMI: 130142 48808
LOC: 2853063066 2853112560
ERR: 12
I have not tried to do anything with interrupt 11 (i.e. bios tweaks or
module
options).
/Allan
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
1:59 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Fri, Apr 20, 2007 at 05:50:59PM +0200, Pieter Palmers wrote:
You should check whether your laptop has a Ricoh 1394
chipset. If it
does, you're out of luck. Ricoh chipsets are buggy in hardware, and
cannot be used for firewire audio interfaces. Thinkpads are known to use
these chipsets.
lspci | grep 1394
My R51 says:
02:00.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 802a (rev 01)
Would that work ?
--
FA
Follie! Follie! Delirio vano è questo !
2:45 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Fons Adriaensen wrote:
On Fri, Apr 20, 2007 at 05:50:59PM +0200, Pieter
Palmers wrote:
Texas Instruments chipsets should work fine. VIA chipsets should also
work fine. I've seen vendors that recommend not to use NEC chipset, but
I have a NEC based cardbus card that works fine for me.
Note that this Ricoh thing is not something Linux specific... search the
digidesign or presonus forums for ricoh and you'll see that it's a
common problem.
Maybe we (=FFADO) should also build a chipset database....
Pieter
You should check whether your laptop has a Ricoh
1394 chipset. If it
does, you're out of luck. Ricoh chipsets are buggy in hardware, and
cannot be used for firewire audio interfaces. Thinkpads are known to use
these chipsets.
lspci | grep 1394
My R51 says:
02:00.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 802a (rev 01)
Would that work ?
2:51 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
yes
I confirm that Ricoh chipset doesn't work for me and my presonus Firebox.
Erwan
2007/4/20, Pieter Palmers <pieterp(a)joow.be>be>:
Fons Adriaensen wrote:
(rev 01)
On Fri, Apr 20, 2007 at 05:50:59PM +0200, Pieter
Palmers wrote:
> You should check whether your laptop has a Ricoh 1394 chipset. If it
> does, you're out of luck. Ricoh chipsets are buggy in hardware, and
> cannot be used for firewire audio interfaces. Thinkpads are known to
use
these
chipsets.
lspci | grep 1394
My R51 says:
02:00.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 802a
Would that work ?
Texas Instruments chipsets should work fine. VIA chipsets should also
work fine. I've seen vendors that recommend not to use NEC chipset, but
I have a NEC based cardbus card that works fine for me.
Note that this Ricoh thing is not something Linux specific... search the
digidesign or presonus forums for ricoh and you'll see that it's a
common problem.
Maybe we (=FFADO) should also build a chipset database....
Pieter
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
19 Apr
19 Apr
11:12 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Thu, 2007-04-19 at 12:55 -0700, Ken Dawson wrote:
I had one of those fairly pricey decisions to make recently also, after
my gateway mx6124 bit the dust. I was bummed, as the firewire was on
it's own interrupt on that machine.
Here is the interrupts for a lenovo z61m:
CPU0 CPU1
0: 7694732 0 IO-APIC-edge timer
1: 1784 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 4089 2632 IO-APIC-fasteoi acpi
12: 377309 0 IO-APIC-edge i8042
14: 36907 30962 IO-APIC-edge ide0
16: 342588 189959 IO-APIC-fasteoi yenta, uhci_hcd:usb1,
libata, tifm_7xx1, sdhci:slot0, fglrx, eth0
17: 63422 3581 IO-APIC-fasteoi uhci_hcd:usb2, HDA Intel,
ohci1394, ipw3945
18: 69 0 IO-APIC-fasteoi uhci_hcd:usb3
19: 275375 0 IO-APIC-fasteoi uhci_hcd:usb4,
ehci_hcd:usb5
NMI: 0 0
LOC: 7694609 7658005
ERR: 0
I haven't done any real audio work yet, but interestingly enough, I
can't get the intel wireless radio to work on the planetccrma kernel,
but I am going to take that as a blessing as it will be one less
interrupt when I am doing serious audio work...
/PF
Robin Gareus
wrote:
[snip]
>
> thinkpad x60s:
>
> CPU0 CPU1
> 0: 352029528 0 IO-APIC-edge timer
> 1: 1251013 0 IO-APIC-edge i8042
> 8: 0 0 IO-APIC-edge rtc
> 9: 65043220 0 IO-APIC-fasteoi acpi
> 12: 10126775 0 IO-APIC-edge i8042
> 20: 35583442 20485440 IO-APIC-fasteoi yenta,
> i915@pci:0000:00:02.0, uhci_hcd:usb1
> 21: 200293604 250337407 IO-APIC-fasteoi ohci1394, ipw3945, HDA
> Intel, uhci_hcd:usb2
> 22: 65491123 0 IO-APIC-fasteoi sdhci:slot0, uhci_hcd:usb3
> 23: 745166 1065462 IO-APIC-fasteoi ehci_hcd:usb5,
> uhci_hcd:usb4
> 218: 1670650 179 PCI-MSI-edge eth1
> 219: 810037 3174745 PCI-MSI-edge libata
> NMI: 0 0
> LOC: 107326912 241228138
> ERR: 0
> MIS: 0
Hi again,
The other question I have (as I am preparing to make a fairly pricey
decision) is whether anyone could provide this type of information for
the Lenovo t60p, or t60.
Thanks,
/ken _______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
20 Apr
20 Apr
2:12 p.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
At Thu, 19 Apr 2007 20:10:14 -0500,
Peter Finnegan wrote:
On Thu, 2007-04-19 at 12:55 -0700, Ken Dawson wrote:
I had one of those fairly pricey decisions to make recently also, after
my gateway mx6124 bit the dust. I was bummed, as the firewire was on
it's own interrupt on that machine.
Here is the interrupts for a lenovo z61m:
CPU0 CPU1
0: 7694732 0 IO-APIC-edge timer
1: 1784 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 4089 2632 IO-APIC-fasteoi acpi
12: 377309 0 IO-APIC-edge i8042
14: 36907 30962 IO-APIC-edge ide0
16: 342588 189959 IO-APIC-fasteoi yenta, uhci_hcd:usb1,
libata, tifm_7xx1, sdhci:slot0, fglrx, eth0
17: 63422 3581 IO-APIC-fasteoi uhci_hcd:usb2, HDA Intel,
ohci1394, ipw3945
18: 69 0 IO-APIC-fasteoi uhci_hcd:usb3
19: 275375 0 IO-APIC-fasteoi uhci_hcd:usb4,
ehci_hcd:usb5
NMI: 0 0
LOC: 7694609 7658005
ERR: 0
I haven't done any real audio work yet, but interestingly enough, I
can't get the intel wireless radio to work on the planetccrma kernel,
but I am going to take that as a blessing as it will be one less
interrupt when I am doing serious audio work...
On Lenovo *60 laptops, make sure that you enabled modem on BIOS.
Otherwise both sound and wireless may hang due to a BIOS problem. A
workaround is to add probe_mask=1 option to snd-hda-intel (force to
ignore modem).
Also, enable_msi=1 option for snd-hda-intel is worth to try.
This doesn't work reliably on many hardwares, though.
Takashi
Robin
Gareus wrote:
[snip]
>
> thinkpad x60s:
>
> CPU0 CPU1
> 0: 352029528 0 IO-APIC-edge timer
> 1: 1251013 0 IO-APIC-edge i8042
> 8: 0 0 IO-APIC-edge rtc
> 9: 65043220 0 IO-APIC-fasteoi acpi
> 12: 10126775 0 IO-APIC-edge i8042
> 20: 35583442 20485440 IO-APIC-fasteoi yenta,
> i915@pci:0000:00:02.0, uhci_hcd:usb1
> 21: 200293604 250337407 IO-APIC-fasteoi ohci1394, ipw3945, HDA
> Intel, uhci_hcd:usb2
> 22: 65491123 0 IO-APIC-fasteoi sdhci:slot0, uhci_hcd:usb3
> 23: 745166 1065462 IO-APIC-fasteoi ehci_hcd:usb5,
> uhci_hcd:usb4
> 218: 1670650 179 PCI-MSI-edge eth1
> 219: 810037 3174745 PCI-MSI-edge libata
> NMI: 0 0
> LOC: 107326912 241228138
> ERR: 0
> MIS: 0
Hi again,
The other question I have (as I am preparing to make a fairly pricey
decision) is whether anyone could provide this type of information for
the Lenovo t60p, or t60.
Thanks,
/ken
10 Apr
10 Apr
10:40 a.m.
New subject: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
CC: Linux-Audio-Developers
CC: linux1394-devel
Spencer Russell wrote:
Hey List,
So my initial concerns that the HDA Intel audio card shares the IRQ
with ohci1394 seem to have manifested themselves. Using the kernel
option pci=noacpi initially put most of my devices on IRQ11, but then
I was able to move them around using the BIOS. Unfortunately, whenever
I change the IRQs around, HDA Intel, ohci1394, and uhci_hcd:usb2 all
seem to move together, which to me indicates that there's some
lower-level hardware connection between the three of them.
This means that I get loads of xruns if I try to run jackd with a
firewire hard drive plugged in, which is a pain because I bought this
enclosure specifically so that I would have access to the hard drive
that has all my session files on it.
The current interrupt handler for ohci1394 is rather heavyweight. This
could cause these problems. However, ohci1394 is open source, so we can
solve that if we want to :).
You should try the new juju stack, and see if you experience the same
issues there.
I'm also wondering why/whether threaded IRQ's can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
Greets,
Pieter
12:18 p.m.
New subject: [LAD] Re: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Tue, 2007-04-10 at 14:34 +0200, Pieter Palmers wrote:
I'm also wondering why/whether threaded IRQ's
can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
yes, thats correct. the priority of the IRQ itself is based in h/w, and
is not affected by the scheduling class or priority of the kernel task
that runs the *_handle_irq(). the point of ingo's changes are that
*_handle_irq() runs in a dedicated task/thread per IRQ at a (relatively)
fixed priority.
3:41 p.m.
New subject: [LAD] Re: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Paul Davis wrote:
On Tue, 2007-04-10 at 14:34 +0200, Pieter Palmers
wrote:
I think we're not on the same track here...
This is how I understand things:
The IRQ priorities are indeed hardware fixed, in the sense that if two
IRQ's occur simultaneously, that the order of handling them is hardware
based. [=what you say]
The IRQ handler 'vectors' are called by the hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Example:
What I see on my laptop is:
$ cat /proc/interrupts:
...
9: 2210709 XT-PIC-XT ipw2200, Intel 82801DB-ICH4,
Intel 82801DB-ICH4 Modem, eth0
...
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9 FF 50
What I would like to see is:
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9-ipw2200 TS -
IRQ-9-snd FF 50
IRQ-9-eth0 TS -
That would restrict the critical path whenever IRQ-9 is called to the
kernel's dispatch function for the interrupt.
Greets,
Pieter
I'm also wondering why/whether threaded
IRQ's can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
yes, thats correct. the priority of the IRQ itself is based in h/w, and
is not affected by the scheduling class or priority of the kernel task
that runs the *_handle_irq(). the point of ingo's changes are that
*_handle_irq() runs in a dedicated task/thread per IRQ at a (relatively)
fixed priority. 
4:21 p.m.
New subject: [LAD] Re: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Tuesday 10 April 2007, Pieter Palmers wrote:
The IRQ handler 'vectors' are called by the
hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Yes, that would be nice. I'm pretty sure Ingo thought of this before himself.
I suspect practical reasons [i.e. too much work] for this not being
implemented. Am i right, Ingo [CC'ed]?
Regards,
Flo
P.S.: Took LAD/LAU/1394 from the CC list. dunno if Ingo is subscribed..
--
Palimm Palimm!
http://tapas.affenbande.org
4:40 p.m.
New subject: [LAD] Re: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Florian Schmidt wrote:
On Tuesday 10 April 2007, Pieter Palmers wrote:
me too actually ;)
The IRQ handler 'vectors' are called by
the hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Yes, that would be nice. I'm pretty sure Ingo thought of this before himself.
I suspect practical reasons [i.e. too much work] for
this not being
implemented. Am i right, Ingo [CC'ed]?
I don't think it's that much work, but there might be caveats that are
not really apparent on first sight. If this isn't the case, I might try
and cook up a patch that can trigger the open source process.
Pieter
11 Apr
11 Apr
4:17 a.m.
New subject: [LAD] Re: Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On 4/10/07, Pieter Palmers <pieterp(a)joow.be> wrote:
Florian Schmidt wrote:
I don't think this would help - with threaded interrupts the kernel
masks the irq then schedules the handler thread which runs the
registered handlers in sequence, one of which will acks and unmask it.
The kernel does not know which device generated the interrupt nor is
there a generic mechanism to ack an irq - only the drivers knows how
to do this. So priortizing the handlers for different devices on the
same line buys you nothing - if the firewire hardware interrupts, no
other irqs on that line can be serviced until the firewire ISR has run
and acked the IRQ.
Excessively shared interrupts are a legacy hardware problem, you'll
never solve it in software. The solution is APIC and MSI and the
like.
There is a potential for microoptimization: currently when a shared
IRQ is raised the kernel runs all the registered handlers in the order
they were registered (aka driver load order). So it's possible for
another driver on the same IRQ to delay the handling of time critical
IRQs if it takes a long time for the ISR to determine whether it's
device generated this interrupt. This could be improved by extending
the meaning of SA_INTERRUPT flag to insert this handler at the head of
the chain.
Lee
On Tuesday 10 April 2007, Pieter Palmers wrote:
me too actually ;)
The IRQ handler 'vectors' are called by
the hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Yes, that would be nice. I'm pretty sure Ingo thought of this before himself. I suspect practical reasons [i.e. too much work]
for this not being
implemented. Am i right, Ingo [CC'ed]?
I don't think it's that much work, but there might be caveats that are
not really apparent on first sight. If this isn't the case, I might try
and cook up a patch that can trigger the open source process.
6480
days inactive
6491
days old
linux-audio-user@lists.linuxaudio.org
58 comments
18 participants
participants (18)
-
Allan Wind -
Arnold Krille -
Dmitry Baikov -
Dragan Noveski -
Florian Schmidt -
Fons Adriaensen -
Geoff Beasley -
Ken Dawson -
Lee Revell -
mea -
Mysth-R -
Paul Davis -
Peter Finnegan -
Pieter Palmers -
Robin Gareus -
Sampo Savolainen -
Spencer Russell -
Takashi Iwai