I have a cheapo OSS-supported soundcard in a 2.4 kernel linux and am trying PD-.35-26.
I was getting pure noise on the outputs and "OSS: DSP format: wanted 1024, got 16" so I investigated. It seems the s_linux.c file doesn't handle cards (or older OSS apis, not sure) that don't support 32-bit samples.
i.e. line 864 s_linux.c: if ((ioctl(fd,SNDCTL_DSP_GETFMTS,¶m) >= 0) && (param & AFMT_S32_BLOCKED)) Always returns true in my case: SNDCTL_DSP_GETFMTS returns 1048 (1024+16+8). The mask defined there for 32-bit samples (which I've only so far seen for RME cards) is 1024. I'm not sure why DSP_GETFMTS is returning a 1024 when the API hasn't heard of 32-bit samples yet. (i.e., when it tries to actually DSP_SETFMT that mask, it stops with an error.)
I guess my questions are: 1) is AFMT_S32* defined in a newer OSS spec that I just don't have yet? 2) Does anyone know why a card would return a 1024 in its capable-mask if it can't set it?
To fix the situation on my machine, I just commented out that check and left it at AFMT_S16_NE.
Also, p.s.: KDE's aRts completely confuses the OSS startup routine in PD. I had to disable it.
-- Brian Whitman - bwhitman@media.mit.edu http://www.media.mit.edu/~bwhitman Music, Mind & Machine Group MIT Media Lab
Hi, Brian Whitman hat gesagt: // Brian Whitman wrote:
I have a cheapo OSS-supported soundcard in a 2.4 kernel linux and am trying PD-.35-26.
I was getting pure noise on the outputs and "OSS: DSP format: wanted 1024, got 16" so I investigated. It seems the s_linux.c file doesn't handle cards (or older OSS apis, not sure) that don't support 32-bit samples.
Not an answer, but: Did you try ALSA?
ciao,
Frank Barknecht _ ______footils.org__
HI Brian,
I think the 32 bit format isn't standard in Linux. I too wonder what the 1024 bit means to your driver, but it sounds as if I have to find a better way of checking this.
One possibility would be to add a -16bit flag which would make Pd prefer to use 16 bit audio. I'd be happy to do this if nobody can think of a more canonical way to go about it...
cheers -- and thanks for flagging this! Miller
On Thu, Jun 13, 2002 at 11:26:36AM -0400, Brian Whitman wrote:
I have a cheapo OSS-supported soundcard in a 2.4 kernel linux and am trying PD-.35-26.
I was getting pure noise on the outputs and "OSS: DSP format: wanted 1024, got 16" so I investigated. It seems the s_linux.c file doesn't handle cards (or older OSS apis, not sure) that don't support 32-bit samples.
i.e. line 864 s_linux.c: if ((ioctl(fd,SNDCTL_DSP_GETFMTS,¶m) >= 0) && (param & AFMT_S32_BLOCKED)) Always returns true in my case: SNDCTL_DSP_GETFMTS returns 1048 (1024+16+8). The mask defined there for 32-bit samples (which I've only so far seen for RME cards) is 1024. I'm not sure why DSP_GETFMTS is returning a 1024 when the API hasn't heard of 32-bit samples yet. (i.e., when it tries to actually DSP_SETFMT that mask, it stops with an error.)
I guess my questions are: 1) is AFMT_S32* defined in a newer OSS spec that I just don't have yet? 2) Does anyone know why a card would return a 1024 in its capable-mask if it can't set it?
To fix the situation on my machine, I just commented out that check and left it at AFMT_S16_NE.
Also, p.s.: KDE's aRts completely confuses the OSS startup routine in PD. I had to disable it.
-- Brian Whitman - bwhitman@media.mit.edu http://www.media.mit.edu/~bwhitman Music, Mind & Machine Group MIT Media Lab
On Thu, 13 Jun 2002, Miller Puckette wrote:
HI Brian,
I think the 32 bit format isn't standard in Linux. I too wonder what the 1024 bit means to your driver, but it sounds as if I have to find a better way of checking this.
One possibility would be to add a -16bit flag which would make Pd prefer to use 16 bit audio. I'd be happy to do this if nobody can think of a more canonical way to go about it...
no new flags, please, and if so, the other way round. Default is 16 bit, if (the reintroduced) -rme flag is present try 32.
There is no other card for OSS that supports 32 bit AFAIK. OSS kernel interface will die, I don't want to try to push new formats into it.
The way to go is definitely ALSA, or better jack (jackit.sourceforge.net). The jack audio server allows several applications to share the sound device, it is supposed to be low latency and it is callback based. (and has a simpler API, only floating point format, non-interleaved samples, which all fits pd very well).
In order to make it work on OSS based systems too, jack can easily be extended by a OSS backend, which would make it runable with boths API's and pd doesn't have to care about them anymore.
I am willing to implement this, if we can agree on it.
All of this has to be seen in a larger context, because the resurrection of the DeMuDi distribution has as one goal to be based on the Jack server for doing AudioI/O.
Well, I hope we can manage to show pd at its best within this distribution, with all externals, docs, examples, etc etc that all people are contributing here ...
Guenter
Hi all,
Well, I for one can't get the Alsa driver running with my RME cards (on either of two machines I've tried.) I bet there are others in the same situation. So I'm stuck offering Pd support for that at least until the ALSA folks improve their installation scene...
(by the way, does anyone else have insmod fail not finding the RME board ---which I think is distinct from not being able to allocate the memory)...?
cheers Miller
On Fri, Jun 14, 2002 at 09:53:35AM +0200, günter geiger wrote:
On Thu, 13 Jun 2002, Miller Puckette wrote:
HI Brian,
I think the 32 bit format isn't standard in Linux. I too wonder what the 1024 bit means to your driver, but it sounds as if I have to find a better way of checking this.
One possibility would be to add a -16bit flag which would make Pd prefer to use 16 bit audio. I'd be happy to do this if nobody can think of a more canonical way to go about it...
no new flags, please, and if so, the other way round. Default is 16 bit, if (the reintroduced) -rme flag is present try 32.
There is no other card for OSS that supports 32 bit AFAIK. OSS kernel interface will die, I don't want to try to push new formats into it.
The way to go is definitely ALSA, or better jack (jackit.sourceforge.net). The jack audio server allows several applications to share the sound device, it is supposed to be low latency and it is callback based. (and has a simpler API, only floating point format, non-interleaved samples, which all fits pd very well).
In order to make it work on OSS based systems too, jack can easily be extended by a OSS backend, which would make it runable with boths API's and pd doesn't have to care about them anymore.
I am willing to implement this, if we can agree on it.
All of this has to be seen in a larger context, because the resurrection of the DeMuDi distribution has as one goal to be based on the Jack server for doing AudioI/O.
Well, I hope we can manage to show pd at its best within this distribution, with all externals, docs, examples, etc etc that all people are contributing here ...
Guenter
On Thu, 13 Jun 2002, Brian Whitman wrote:
I have a cheapo OSS-supported soundcard in a 2.4 kernel linux and am trying PD-.35-26.
I was getting pure noise on the outputs and "OSS: DSP format: wanted 1024, got 16" so I investigated. It seems the s_linux.c file doesn't handle cards (or older OSS apis, not sure) that don't support 32-bit samples.
i.e. line 864 s_linux.c: if ((ioctl(fd,SNDCTL_DSP_GETFMTS,¶m) >= 0) && (param & AFMT_S32_BLOCKED))
This is definitely my fault. I haven't hardcoded the ID of the RME formats in the soundcard.h file of the kernel, now the same are taken away by AC3 or so. ... The solutions are to change the AFMT_S32_BLOCKED define at the start of s_linux, I have to do so in my driver too, or to make pd runnable with the RME ALSA driver, of even better with jack.
Guenter
-
Brian Whitman -
Frank Barknecht -
g�nter geiger -
Miller Puckette