Is anybody still using OSS ?

[Werner Van Belle]

Hello,

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,-

[igorzwx]

Hello,

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 for
Beta 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/

There is already a kind of "bpmdj" in AUR. Is it yours?

Code: Select all

$ yaourt bpmdj
1 aur/bpmdj 4.1-1 (10)
    Tool for detecting the BPM of mp3, ogg, m4a, mpc and flac files
==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3)
==> -------------------------------------------------------
==>

http://aur.archlinux.org/packages.php?ID=29366
bpmdj 4.1-1
http://bpmdj.yellowcouch.org/index.html
Tool for detecting the BPM of mp3, ogg, m4a, mpc and flac files
Submitter: BertiBoeller
Maintainer: None
Votes: 10

EDIT: Although 10 votes in AUR is not a very great score, it means that at least ten persons tried bpmdj and found it useful.

[cesium]

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?)

[Werner Van Belle]

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:

Code: Select all

  p=playrate;
  int r=ioctl(dsp,SNDCTL_DSP_SPEED,&p);
  if (r==-1)
    Error(ui,"Setting Oss driver speed (%d) failed.");
  if (playrate!=p)
    {
      Info("actual playrate is %d, requested playrate was %d\n",p,playrate);
      playrate=p;
    }


but as stated in the documentation (that p will contain the actual playrate), that doesn't happen. Actually, not even an error is given.

[cesium]

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:

#ifdef SOUND_PCM_READ_RATE
ioctl (fd, SOUND_PCM_READ_RATE, &p);
#else
p = 0;
ioctl (fd, SNDCTL_DSP_SPEED, &p);
#endif
]

[Werner Van Belle]

Yes, but it ain't 'invisible'. The sound plays too fast or too slow if the app assumes that the playrate is indeed correctly reported. So how can I know the actual playrate then ?

[cesium]

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]

[Werner Van Belle]

Na ja, thanks. That SND_PCM_READ_RATE doesn't exist on my system (kernel 2.6.34). From which version on was it introduced ?

[cesium]

It's SOUND_PCM_READ_RATE. As I said, I do find this querying unnecessary... [Edit: (And note OSS4 implementation doesn't have that ioctl anymore, so the #ifdef is necessary)].

[Werner Van Belle]

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.

[cesium]

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.