17 May
2010
17 May
'10
7:36 a.m.
On Sun, 2010-05-16 at 23:59 -0400, Rick Green wrote:
Most probably whatever happened to jack (with regards to the sound card)
completely hoses the system (driver/hardware/whatever). This is good in
the sense basic audio seems to be working.
Jack uses the most efficient way to access the soundcard and some
hardware is not good enough.
Well, I would __first__ try testing out jack and making sure it works.
Once it starts and runs solidly, then try other things. Ardour with a
non-working jack will not do much (which is what is happening to you).
Start small. Did you try the simple command line I suggested?:
jackd -R -d alsa -d hw:0
(which could even be "jackd -d alsa -d hw:0", you don't need rt to test)
Does it start? What does it print? (add "-v" for more details). Is there
anything in the output of dmesg after running that that looks like a
kernel error?
What I would try if that does not work (and you may need to reboot if it
really messes up things again) is:
jackd -R -d alsa -d hw:0 -p 1024 -n 3
That would increase the number of periods to 3 (you can also try 4)
which seems to make some cards work (specially hda variants). Depends on
the hardware...
-- Fernando
On Sun, 16 May 2010, Fernando Lopez-Lezcano wrote:
Thanks. I don't think I have worked with this one before.
For starters tell us which soundcard you have,
that could help
("cat /proc/asound/cards").
[rtg@angel ~]$ cat /proc/asound/cards
0 [SI7012 ]: ICH - SiS SI7012
SiS SI7012 with ALC655 at irq 18 Do you have a
.wav file handy? You could try playing that using aplay.
That is, in a terminal type "aplay NAME_OF_WAV_FILE.wav". Do you get
sound? Any errors? Is the level up? (there should be a small "speaker"
icon in your top panel, use it to bring up the level).
Well, it seems to be
working now. I mounted my home partition from the
US10.04 system, and began to wander thru it looking for .wav files. When
I encountered one, as soon as I hovered the mouse over it, I began to hear
the piece coming from my speakers.
I then went to the 'sound' preferences panel, and clicked on the various
alert sonds presented there. Each one played itself just fine. This
particular exercise is the one that 'confirmed' to me that it wasn't
working an hour ago. No changes since then other than a reboot. AFAIK fc12
uses the "normal" grub? I'm not sure. _Some_ distro had
switched to grub2 but I don't know which. Argh.......
I got around that by booting from the US10.04 DVD and selecting
'rescue',
then re-writing its MBR to the second HDD. Now I can use the BIOS boot
menu to select which HDD to look at, and I've got a triple-boot system
again.
Moving on -
I launched Ardour, opening the 'test' session I had started earlier. I imported a stereo .wav file into a new track, and
attempted to play it.
Same as before: clicking the 'play' button does nothing. The playhead
doesn't move, clock doesn't count, etc. This time, however, the 'go to
start' and 'go to end' buttons do work.
When I try to close the session, Ardour locks up completely. The
'session' menu doesn't even disappear...
top shows me that ardour is still grabbing some cpu cycles every few
seconds, but jackd doesn't show up at all.
`ps aux' shows me this:
[rtg@angel ~]$ ps aux | grep jack
rtg 2234 0.0 3.7 90208 76936 ? SLsl 23:42 0:00
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2252 0.0 0.0 4212 712 pts/1 S+ 23:55 0:00 grep jack
[rtg@angel ~]$ ps aux | grep ardour
rtg 2206 2.9 5.8 298672 120568 ? SLl 23:42 0:22
/usr/lib/ardour2/ardour-2.8.7
rtg 2233 0.0 0.0 0 0 ? Z 23:42 0:00
[ardour-2.8.7] <defunct>
rtg 2254 0.0 0.0 4212 716 pts/1 S+ 23:55 0:00 grep
ardour