Hi there.
I was interested to try out pd after reading about it in Linux User and Developer magazine. I have had some problems getting it running though. Currently, I am failing to get any audio through alsa, oss or jack. Also, however I run it, the interface is REALLY slow. With new windows opening taking at least 10-20 seconds. In particular, anything i seem to click on the testtone.pd (Media->Test Audio and Midi) window takes at least 30 seconds to respond.
These are the error messages (relating to OSS) I get when I run pd -verbose (but I get no sound): opened /dev/dsp for reading and writing
opened audio output on /dev/dsp; got 2 channels bytes per sample = 2 setting nfrags = 8, fragsize 1024
audiobuffer set to 50 msec OSS: requested audio buffer size 8820 limited to 8192 opened audio input device /dev/dsp; got 2 channels bytes per sample = 2 OSS: issuing first ADC 'read' ... Pd: system call timed out ...done.
When I specify -alsa on the command line, I get the following message, about 1 second after the program starts: audio I/O stuck... closing audio
When I try with the -jack switch instead, none of alsa, oss or jack are selected in the media menu, even if I try to select it, I get no output, and the Audio Settings dialog will not work. Also, there appears to be no extra clients in jack.
The compute audio switch is responsive, but it doesn't seem to make a difference to the audio with it being on.
I have tried using the current gentoo portage ebuild, pd-0.37.1 and now, I have ./configure, make, make installed pd-0.38-0test8. Both have the same issues. Other software versions, all using gentoo portage: jackd 0.98.1, alsa-lib 1.0.5, tk 8.3.4-r1, tcl 8.3.4. I'm running linux 2.6.8.1 with the realtime-lsm module in and loaded with the correct group for me set. My alsa driver is via82xx and my audio hardware is the chipset found on an Asus A7V600 motherboard. It's listed in /proc/pci thus:
Bus 0, device 17, function 5: Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 96). IRQ 11. I/O at 0xe000 [0xe0ff].
It seems to work fine with jackd and all alsa applications. Below I've put my /proc/cpuinfo if it's any use and I have 512MB of memory on this machine.
If anyone can offer me any hints, I would be very greatful.
-bill
/proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2000+ stepping : 1 cpu MHz : 1667.523 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 3284.99
Hallo, William Robinson hat gesagt: // William Robinson wrote:
I have had some problems getting it running though. Currently, I am failing to get any audio through alsa, oss or jack. Also, however I run it, the interface is REALLY slow. With new windows opening taking at least 10-20 seconds. In particular, anything i seem to click on the testtone.pd (Media->Test Audio and Midi) window takes at least 30 seconds to respond.
Strange, strange, ...
These are the error messages (relating to OSS) I get when I run pd -verbose (but I get no sound):
Could you try to run Pd with "-noadc" to not use full-duplex? Also: If you run Pd without audio at all ("pd -noaudio") is it still that sluggish?
Ciao
Frank Barknecht _ ______footils.org__
On Mon, 2004-10-11 at 21:43, Frank Barknecht wrote:
Strange, strange, ...
These are the error messages (relating to OSS) I get when I run pd -verbose (but I get no sound):
Could you try to run Pd with "-noadc" to not use full-duplex? Also: If you run Pd without audio at all ("pd -noaudio") is it still that sluggish?
-noadc seemed to fix the responsiveness and OSS and ALSA worked using it, but not jack though. Well, I mean the test tone worked. -noaudio worked as well (of course?), but I'm guessing that it's not quite as useful.
Thanks for the help. Is there anything that I can do to get full-duplex working? It works with most other programs.
-bill
Hallo, William Robinson hat gesagt: // William Robinson wrote:
On Mon, 2004-10-11 at 21:43, Frank Barknecht wrote:
Strange, strange, ...
These are the error messages (relating to OSS) I get when I run pd -verbose (but I get no sound):
Could you try to run Pd with "-noadc" to not use full-duplex? Also: If you run Pd without audio at all ("pd -noaudio") is it still that sluggish?
-noadc seemed to fix the responsiveness and OSS and ALSA worked using it, but not jack though. Well, I mean the test tone worked. -noaudio worked as well (of course?), but I'm guessing that it's not quite as useful.
Not useful, but I was trying to rule out some other possibilities for the sluggish behaviour. But it seems, this is related to the sound input or at least the sound in full duplex. (You could try to use "-nodac" to check the other end of half duplex as well to see if Pd then still is sluggish.)
Thanks for the help. Is there anything that I can do to get full-duplex working? It works with most other programs.
I have really no idea and I think this somehow is strange behaviour and Pd /should/ work with the AC97 chip.
Something else to try would be different combinations of samplerate and maybe buffer/period sizes (-r/-blocksize in pd).
Then in the end, if you intend to do a bit more serious work with sound (not only using Pd) I would recommend to get a real soundcard anyway. Even a cheap old SBLive will work much better than the Via- or any other AC97-chip, and those more expensive cards based on the ICE1712 or similar chips are generally working very well, too.
Ciao
Frank Barknecht _ ______footils.org__
hi,
i've got a machine with the same audio chip (yet maybe a slightly different version)
I have really no idea and I think this somehow is strange behaviour and Pd /should/ work with the AC97 chip.
actually it does for me. but it only did so when run over alsa in my case - and even then i got loads of drop outs.
i think you should really try to get alsa running ... if the chip works in other alsa apps in duplex?
lg martin
attacksyour.net/pi
On Tue, 2004-10-12 at 09:54, martin pichlmair wrote:
hi,
i've got a machine with the same audio chip (yet maybe a slightly different version)
I have really no idea and I think this somehow is strange behaviour and Pd /should/ work with the AC97 chip.
actually it does for me. but it only did so when run over alsa in my case - and even then i got loads of drop outs.
i think you should really try to get alsa running ... if the chip works in other alsa apps in duplex?
Ok. It seems that my problems are running a little deeper than I thought. Previously, soundtracker, using the oss interface and jack, using alsa had been working both in full duplex, though i've just tried these again and now very little seems to be working properly. This is really annoying as I don't think I've changed anything since it was working a few days ago.
I will be back at it when I work out what has gone wrong with alsa. I think the only thing that I have done recently is add the following modules to be autoloaded on boot: realtime gid=18 snd-pcm-oss snd-seq-oss snd-mixer-oss
Thanks for your time. -bill
Ok. It seems that my problems are running a little deeper than I thought. Previously, soundtracker, using the oss interface and jack, using alsa had been working both in full duplex, though i've just tried these again and now very little seems to be working properly. This is really annoying as I don't think I've changed anything since it was working a few days ago.
After sharing my alsa mixer state with a guy on freenode in #alsa, it turns out that I had a switch set wrong in my alsa mixer. I don't remember switching it over recently, but maybe I did.
Sorry for being stupid. bill
Hi again.
the sluggish behaviour. But it seems, this is related to the sound input or at least the sound in full duplex. (You could try to use "-nodac" to check the other end of half duplex as well to see if Pd then still is sluggish.)
Ok, I'll try to do this in a bit more of an scientific way.
OSS, Full-Duplex No audio in or out at all. GUI very unresponsive as described before. I've tried using a variety of blocksizes 8192 and 1024. Also, I tried a variety of sample rates: 48000, 44100, 24000 and 22050. Getting these messages on the output:
OSS: issuing first ADC 'read' ... Pd: system call timed out ...done.
OSS, Half-Duplex, -nodac, Input only Again, very sluggish/unresponsive. At all sample rates, getting some evidence of audio input, where the first two numbers connected to the "pd -------audio----" object get set to values around 36 and 34 or 39 and 35 after the window has been open for a few seconds, regardless of whether I make any input at all. Still get the "Pd: system call timed out" messages as above. Tried it with the blocksizes and sample rates above without much difference between them.
OSS, Half-Duplex, -noadc, Output only Very responsive, everything seems to work ok. All the blocksizes and sample rates worked fine.
ALSA, Full-Duplex GUI responsive, but no evidence of sound in or out. Tried using same sample rates and both of my audio devices listed, 1 and 2, being hw:0 and plughw:0. All of them gave output similar to this:
input channels = 2, output channels = 2 device name plughw:0; channels in 2, out 2 audio buffer set to 50 opening sound input... Sample width set to 4 bytes opening sound output... audio I/O stuck... closing audio
That last line appears about a second after the rest of them and I get no audio still.
ALSA, Half-Duplex -noadc This gives pretty much the same behavior as alsa in full-duplex mode, but without the audio out messages, of course.
So, to summarise, it seems that I just have a problem with my input. Trying to use any kind of audio input causes me to get no audio at all. And additionally, on OSS, causes the application to slow up to unusable speeds (but top says it doesn't take up much cpu time).
Any other ideas? Thanks. bill
Thanks for the help. Is there anything that I can do to get full-duplex working? It works with most other programs.
I have really no idea and I think this somehow is strange behaviour and Pd /should/ work with the AC97 chip.
Something else to try would be different combinations of samplerate and maybe buffer/period sizes (-r/-blocksize in pd).
Then in the end, if you intend to do a bit more serious work with sound (not only using Pd) I would recommend to get a real soundcard anyway. Even a cheap old SBLive will work much better than the Via- or any other AC97-chip, and those more expensive cards based on the ICE1712 or similar chips are generally working very well, too.
Ciao
-
Frank Barknecht -
martin pichlmair -
William Robinson