hello,
sorry, this one is a bit off topic since it concerns rme sound playback in linux in general...
i have sucessfully installed guenters oss rmexx driver which (congratulations !!) comes officially with kernel 2.4.9
i can play back a single stereo soundfile, but playback will stutter as long as the harddisc gets busier. eg. i can't play 2 soundfiles simultaneosly under pd
i 've been playing around with many combinations of pd flags including realtime and pd suid root with no results. also doctoring around with hdparm didn't help.
maybe someone can give me a clue? i also tried to move the card to another slot. i wonder if it is worth to try out alsa now.
win98: ok, but sound playback kept looping forever until i forced the card to use irq 5. (yes - i could use pd under win98 as a last ressort, but i am not really in the mood for it ...)
again, i would be very thankful for any suggestion.
norbert
the box is: debian testing 2.4.9 one ide drive /dev/hda e2fs on / reiserfs on /usr and /home rme hammerfall light athlon 1.4 GHz
hui:/home/norbert/pd/ac_hh# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3).
Master Capable. Latency=8.
Prefetchable 32 bit memory at 0xd0000000 [0xd7ffffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev
0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev
64).
Bus 0, device 7, function 1:
IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6).
Master Capable. Latency=32.
I/O at 0xd000 [0xd00f].
Bus 0, device 7, function 2:
USB Controller: VIA Technologies, Inc. UHCI USB (rev 22).
IRQ 5.
Master Capable. Latency=32.
I/O at 0xd400 [0xd41f].
Bus 0, device 7, function 3:
USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 22).
IRQ 5.
Master Capable. Latency=32.
I/O at 0xd800 [0xd81f].
Bus 0, device 7, function 4:
Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
64).
IRQ 11.
Bus 0, device 7, function 5:
Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 8
0).
IRQ 11.
I/O at 0xdc00 [0xdcff].
I/O at 0xe000 [0xe003].
I/O at 0xe400 [0xe403].
Bus 0, device 12, function 0:
Multimedia audio controller: PCI device 10ee:3fc4 (Xilinx, Inc.) (rev
8).
IRQ 5.
Master Capable. Latency=32.
Non-prefetchable 32 bit memory at 0xdc000000 [0xdcffffff].
Bus 0, device 13, function 0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev
16).
IRQ 11.
Master Capable. Latency=32. Min Gnt=32.Max Lat=64.
I/O at 0xec00 [0xecff].
Non-prefetchable 32 bit memory at 0xde000000 [0xde0000ff].
Bus 1, device 0, function 0:
VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 21).
IRQ 11.
Master Capable. Latency=32. Min Gnt=5.Max Lat=1.
Non-prefetchable 32 bit memory at 0xda000000 [0xdaffffff].
Prefetchable 32 bit memory at 0xd8000000 [0xd9ffffff].
hui:/home/norbert/pd/ac_hh# hdparm -v /dev/hda
/dev/hda: multcount = 16 (on) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 5005/255/63, sectors = 80418240, start = 0
norbert@hui:~$ cat .pdrc -nomidi -frags 1 -outchannels 8 -inchannels 8 -verbose -blocksize 1000 -path /home/norbert/pd/lib -lib zexy
Norbert Math wrote:
i can play back a single stereo soundfile, but playback will stutter as long as the harddisc gets busier. eg. i can't play 2 soundfiles simultaneosly under pd
i 've been playing around with many combinations of pd flags including realtime and pd suid root with no results. also doctoring around with hdparm didn't help.
have you tried the "-c 1" flag for hdparm to enable 32bit-I/O-support ?
the box is: debian testing 2.4.9 one ide drive /dev/hda e2fs on / reiserfs on /usr and /home rme hammerfall light athlon 1.4 GHz
this should definitely rock ! note, that i do not remember having problems with a rme-9652 and kernel-2.4.3 (or something), although i had to compile the kernel myself then. i am sure, that i could play-bac 2 files at least.
which soundfile-player do you use ? under linux i definitely suggest using miller's "readsf" instead of zexy's "sfplay~" !! could this be the problem ?
mfg.cds.saet IOhannes
On Thu, 13 Sep 2001, IOhannes m zmoelnig wrote:
this should definitely rock ! note, that i do not remember having problems with a rme-9652 and kernel-2.4.3 (or something), although i had to compile the kernel myself then. i am sure, that i could play-bac 2 files at least.
which soundfile-player do you use ? under linux i definitely suggest using miller's "readsf" instead of zexy's "sfplay~" !! could this be the problem ?
I don't think so. I'm not sure if the pd-0.34 has the same thing, but the buffersize for the RME is changed to use 64 samples (the smallest buffer you can get for the rme), no matter what buffersize you request.
Linux without the low latency patches isn't suited for this short buffers when doing harddisk I/O.
Even with lowlatency you are living on the edge with this setting.
The only way I found to change this was editting s_linux.c
Guenter
hello, first i want to thank you for the suggestions!
i got the problem near to solved by increasing the buffersize as guenter suggested.
pd 0.34.2, s_linux.c, near line 666: ...
if (linux_fragsize)
/* post("warning: overiding blocksize to 64!");
linux_fragsize = 64; */
post("hack: warning: overiding blocksize to 1024!");
linux_fragsize = 1024;
}
...
i still get loops sometimes - they sound lovlier now :-) but i can rearrange the pd patch o avoid them. on the long run i consider to apply the low-latency kernel patches. (demudi will come with them, i guess?)
thank you all again norbert
On Thu, 13 Sep 2001, guenter geiger wrote:
I don't think so. I'm not sure if the pd-0.34 has the same thing, but the buffersize for the RME is changed to use 64 samples (the smallest buffer you can get for the rme), no matter what buffersize you request.
Linux without the low latency patches isn't suited for this short buffers when doing harddisk I/O.
Even with lowlatency you are living on the edge with this setting.
The only way I found to change this was editting s_linux.c
Guenter
Hi all,
I don't understand why 64 sample buffers should be a problem for RME since you should be able to use many buffers ("fragments") to set the latency to a reasonable value. But perhaps I'm mising something...
cheers Miller
On Thu, Sep 13, 2001 at 02:35:45PM +0200, guenter geiger wrote:
On Thu, 13 Sep 2001, IOhannes m zmoelnig wrote:
this should definitely rock ! note, that i do not remember having problems with a rme-9652 and kernel-2.4.3 (or something), although i had to compile the kernel myself then. i am sure, that i could play-bac 2 files at least.
which soundfile-player do you use ? under linux i definitely suggest using miller's "readsf" instead of zexy's "sfplay~" !! could this be the problem ?
I don't think so. I'm not sure if the pd-0.34 has the same thing, but the buffersize for the RME is changed to use 64 samples (the smallest buffer you can get for the rme), no matter what buffersize you request.
Linux without the low latency patches isn't suited for this short buffers when doing harddisk I/O.
Even with lowlatency you are living on the edge with this setting.
The only way I found to change this was editting s_linux.c
Guenter
My understanding is that the RME has the number of fragments set at 2 as a hardware property. I don't see why the drivers couldn't do more buffering, however.
Karl
On Sun, 23 Sep 2001, Miller Puckette wrote:
Hi all,
I don't understand why 64 sample buffers should be a problem for RME since you should be able to use many buffers ("fragments") to set the latency to a reasonable value. But perhaps I'm mising something...
cheers Miller
On Thu, Sep 13, 2001 at 02:35:45PM +0200, guenter geiger wrote:
On Thu, 13 Sep 2001, IOhannes m zmoelnig wrote:
this should definitely rock ! note, that i do not remember having problems with a rme-9652 and kernel-2.4.3 (or something), although i had to compile the kernel myself then. i am sure, that i could play-bac 2 files at least.
which soundfile-player do you use ? under linux i definitely suggest using miller's "readsf" instead of zexy's "sfplay~" !! could this be the problem ?
I don't think so. I'm not sure if the pd-0.34 has the same thing, but the buffersize for the RME is changed to use 64 samples (the smallest buffer you can get for the rme), no matter what buffersize you request.
Linux without the low latency patches isn't suited for this short buffers when doing harddisk I/O.
Even with lowlatency you are living on the edge with this setting.
The only way I found to change this was editting s_linux.c
Guenter
Karl W. MacMillan Computer Music Department Peabody Institute of the Johns Hopkins University karlmac@peabody.jhu.edu mambo.peabody.jhu.edu/~karlmac
hello, in my own special case i suspect some general kernel incopatibilty problem with the mainboard (chipset via VT82C686B) - i'll dig deeper into it as soon as i have more time (but then i won't need that pd patch anymore, that's life)
hard-coded hacking the buffersize to 1024 helps just to get to 4 track output - any more track blockes again. (and i had to stop cron and any other harddisc consuming task) -
again thank you all for your suggestions - you gave me a lot of insights.
norbert
On Mon, 24 Sep 2001, Karl MacMillan wrote:
My understanding is that the RME has the number of fragments set at 2 as a hardware property. I don't see why the drivers couldn't do more buffering, however.
Karl
On Sun, 23 Sep 2001, Miller Puckette wrote:
Hi all,
I don't understand why 64 sample buffers should be a problem for RME since you should be able to use many buffers ("fragments") to set the latency to a reasonable value. But perhaps I'm mising something...
cheers Miller
On Thu, Sep 13, 2001 at 02:35:45PM +0200, guenter geiger wrote:
On Thu, 13 Sep 2001, IOhannes m zmoelnig wrote:
this should definitely rock ! note, that i do not remember having problems with a rme-9652 and kernel-2.4.3 (or something), although i had to compile the kernel myself then. i am sure, that i could play-bac 2 files at least.
which soundfile-player do you use ? under linux i definitely suggest using miller's "readsf" instead of zexy's "sfplay~" !! could this be the problem ?
I don't think so. I'm not sure if the pd-0.34 has the same thing, but the buffersize for the RME is changed to use 64 samples (the smallest buffer you can get for the rme), no matter what buffersize you request.
Linux without the low latency patches isn't suited for this short buffers when doing harddisk I/O.
Even with lowlatency you are living on the edge with this setting.
The only way I found to change this was editting s_linux.c
Guenter
Karl W. MacMillan Computer Music Department Peabody Institute of the Johns Hopkins University karlmac@peabody.jhu.edu mambo.peabody.jhu.edu/~karlmac