HI all,
In light of all the trouble people are having with "resync" messages, I'm thinking about making "-noresync" the default, at least when running stereo. The "resync" checking is useful when it works, but it seems not to work a lot of the time...
I've tried to recreate Guenter's problem with abstractions and "netreceive"... I couldn't find any problems yet. I tried both "netreceive" and an abstraction in the same patch, and also a "netreceive" inside an abstraction, no problems. The next step would be for Guenter to send me the patch he's running that fails...
Finally, I tried for a while to get MIDI input with an emu10k1 card (SB Live; although I expect to see the same behavior for the cheaper "PCI 512". Note that "PCI 128 has a different, older chip and does not have this problem. It seems that when you're using the emu10k1 driver, select() doesn't report available incoming MIDI bytes, so Wini's s_linux_midi_io code never realizes that there's data to read.
This is all under OSS. I think the next step would be to make a bug report but I can't figure out whether to send to Creative or to whomever provides the OSS audio drivers in teh Linux kernel.
cheers Miller
Miller Puckette writes:
I've tried to recreate Guenter's problem with abstractions and "netreceive"... I couldn't find any problems yet. I tried both "netreceive" and an abstraction in the same patch, and also a "netreceive" inside an abstraction, no problems. The next step would be for Guenter to send me the patch he's running that fails...
Well, it's all resolved now .... the long story is that I had running an older version of pd, while I thought I was running 0.30. The netreceive bug was due to the closing of stdout, but this is fixed in 0.30 ... even abstractions with Gem work now :)
While looking for open() and close() calls I realized that the fclose() for the ".pdrc" file reading is missing in s_path.c:sys_rcfile(). (my fault)
Finally, I tried for a while to get MIDI input with an emu10k1 card (SB Live; although I expect to see the same behavior for the cheaper "PCI 512". Note that "PCI 128 has a different, older chip and does not have this problem. It seems that when you're using the emu10k1 driver, select() doesn't report available incoming MIDI bytes, so Wini's s_linux_midi_io code never realizes that there's data to read.
This is all under OSS. I think the next step would be to make a bug report but I can't figure out whether to send to Creative or to whomever provides the OSS audio drivers in teh Linux kernel.
I have a SBLive lying around here. I might try it with ALSA and look if it works there.
There is a bug database at "http://opensource.creative.com/", but the best and fastest way is to look at the sources.
Guenter
I have a SBLive lying around here. I might try it with ALSA and look if it works there.
if you try it out, please let me know. I have a SBLive...and can only get it working prperly with ALSA...but with OSS emulation. If i start pd with the -alsa option..I just get IO stuck errors.
Just running normally under OSS (from creative) gives me the same IO stuck error.
The only way I got it working is with the ALSA drivers without using the -alsa option...and giving him some -frags
thanks - august.
august writes:
I have a SBLive lying around here. I might try it with ALSA and look if it works there.
if you try it out, please let me know. I have a SBLive...and can only get it working prperly with ALSA...but with OSS emulation. If i start pd with the -alsa option..I just get IO stuck errors.
Just running normally under OSS (from creative) gives me the same IO stuck error.
The only way I got it working is with the ALSA drivers without using the -alsa option...and giving him some -frags
thanks - august.
Ok, looked into it.
I got the fresh snapshot from opensource.creative.com, compiled it against kernel 2.2.12.
pd is working with the -frags option (the -frags option is necessary, because the OSS protocol isn't implemented correctly in the SBLive driver)
MIDI in is not working, but after looking at the SBLive midi code I realized why:
from emu10k1/midi.c:
static unsigned int emu10k1_midi_poll(struct file *file, struct poll_table_struct *wait) { DPF(4, "emu10k1_midi_poll() called\n"); return 0; }
This means that the select call for MIDI can't work, it's plainly not implemented. I will try to fix that now.
Guenter
-
august -
Guenter Geiger -
Miller Puckette