I'm the author of BpmDj (http://bpmdj.yellowcouch.org) and I'm currently considering ditching OSS support since as far as I know nobody uses that anymore in linux. It's all alsa nowadays. Can anybody tell me that I'm wrong (and provide some evidence to that end), or what happened with linux/oss ?

I'm the author of BpmDj (http://bpmdj.yellowcouch.org) and I'm currently considering ditching OSS support since as far as I know nobody uses that anymore in linux. It's all alsa nowadays. Can anybody tell me that I'm wrong (and provide some evidence to that end), or what happened with linux/oss ?

With kind regards,

Werner,-

Thanks for information!

If I understood you correctly, you need beta testers and packagers. Right?

Looking forBeta Testers to test the software while it is being developed.Packagers for slackware, debian, redhat, ubuntu, etcetera.Both get access to the beta version before a new version is released.http://bpmdj.yellowcouch.org/

Well, I don't have any figures or proof about amount of users. I do know that every day when I'm around in the IRC channel, there's one guy asking for help there. That said, I am not sure this is the right question - I think the better question is whether there are bmpdj users which find this useful.

(aside, FreeBSD and Solaris use this API as native, so you may wish to check also if there are users of bmpdj under these platforms - I'm guessing not though from the website?)

Hello, so since it kept on compiling and I only had to make a few modifications I decided to try to keep OSS support in the source.

Now, of course I stumbled upon somewhat of a problem: obtaining the actual playback rate. Is there any call that will return such info ? The documentation states that application should allow a '10% difference in samplerate', which is fine, but if there is a difference I would like to know about it. Currently when setting the samplerate no error is given but obviously the thing plays too fast or too slow.

I also tried to obtain the appropriate playrate when setting the required rate as follows:

Well, the returned rate from SNDCTL_DSP_SPEED is the one used throughout the app's life (or more accurately, the fd), so you can just refer to it. It's not changed unilaterally on an app. If the actual playrate is different from the returned value from SNDCTL_DSP_SPEED, it's only because there's an SRC layer - and that is meant to be invisible from an app.

[edit: It's possible to query the rate (though as I said, you can just store the value), but a bit messy in practice due to compat issues between implementations:

I gave an edit above for how to query it after you responded, but I think you have to trust the drivers at some point... If it 'lies' to you on the returned value from SNDCTL_DSP_SPEED, it can lie to you when querying the rate.

[edit: SRC is sample rate conversion, so in that case the user would hear correctly]

How can you say it is 'unnecessary' ? I have a practical problem that I _need_ to know how fast the audio is being streamed out. If I don't know that, then I cannot make it possible for the enduser to mix two songs. A 10% difference in playingspeed is quite substantial. So, you might find it unnecessary but what I present here are two facts,

a- It seems impossible to set/obtain the correct playing speed and b- The enduser of the application cannot live with a potential 10% difference in playingspeed.

Aside from that: I can easily imagine applications that also want to know the correct playing speed. A digital pitchfork for instance.

Allthough I thank you for the potential solution you offer, your argument 'it ain't necessary' holds no water.

As I said, the returned rate from SNDCTL_DSP_SPEED _is_ the play rate. That's the rate the driver expects the data to be in. There's no reason (or facility) for it to ever change (unless the app decides to change it) so I don't think there's no reason to query it... If you insist on querying it, I showed how to do so.

What I did mention is that some cards have HW mixing (e.g. some SBLives mixed everything to 48000 - including 48000 input!), and quite a few implementations can do their own mixing so the rate at the output might be different, but that's not relevant to the app (in your example, you'd mix the songs to the expected rate, and than the driver/card would convert _the total mixed output_ to another rate). There are good reasons why people want to have mixing above the app level - for example, if two sound clients were playing, but had different rates, the only way to have both at the same time (as most cards only have one rate at output) would be to resample one (or both) so there's the same rate and then send them to the output.