DragonFly kernel List (threaded) for 2007-06
DragonFly BSD
DragonFly kernel List (threaded) for 2007-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: OpenSound - was Re: lockmgr patch

From: Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 15 Jun 2007 21:09:24 -0400

Joerg Sonnenberger wrote:
> On Fri, Jun 15, 2007 at 03:11:02PM +0300, Hasso Tepper wrote:
>> I'm not going to discuss this here. Regardless of your or my opinion I
>> don't see any chance to see community (both users and application writers)
>> behind Linux/Alsa going to care in any way about future of OpenSound.
> I don't think most application writers care at all, because they use
> SDL or other higher-level libraries.
> Joerg

Okay .. so, since this topic is active:


Lots of the folks involved with linux audio (e.g. ALSA / JACK ) are here:


These folks were fairly influential in getting various 'Pseudo-Realtime'
and other scheduler changes into the Linux kernel (see ingo molnar) to
meet latency requirements for using linux as a platform for audio /
multimedia production (e.g. deterministic scheduling useful for hearing
yourself play guitar into the system and not having to adapt to
scheduling jitter) .. lots of interesting music related stuff going on
there (dig around for 'planet ccrma', 'ardour', ubuntustudio, etc.)

Have been following this list for some time, and a lot of the gist of it
in terms of operating systems is " I need audio API XYZ to be able to
handle rigourous scheduling demands via a lock-free callback-based
interface " .. aside from discussion of various sound / dsp processing
techniques, new apps, gui / plugin toolkits, etc. And the results of
their effort are the main reason I keep Linux boxen around.

but in any case.. not really here-or-there w/r/t DragonFly -

back to the topic of audio  / etc:

- Does anyone have any plans to make things pre-emptively multitasked ?

- also .. anyone playing around in general with
  /usr/src/sys/emulation/posix4 , sched_setscheduler, rtrprio,
  etc, etc ?

(secretly hoping that DF will be the NTT Rtmach that wasn't, for audio
 processing purposes .. see http://www.rtmach.org/index-e.html, but this
 is a bit too theoretical already :)

In any case.. the LAD folks (and me :) have a 'real need' for 'an
appropriate' audio API.. I contrast this with folks that just need to
'play sound' - which is most people. No value judgment in that
statement, just facts. If you're playing a video or making a VOIP call,
some mild buffering / jitter is OK such that the playback doesn't skip,
but the guitar scenario above, this is a problem (TM).

It seems like most of the 'more demanding' users were influential in
getting the ALSA api off the ground (again, from an outsiders perspetive
- I mostly lurk on that list ), along with GNU-influenced concerns about
the previously-proprietary nature of OSS.

But at the same time, it seems like the OSS api is alot simpler and
cleaner for the 'just play sound' case.. this is my 2c, not having
written much audio code at all.

in any case, this list is worth a read from time to time, so FYI.

2) Being mildly interested in the topic of computer sound myself (see #1
 & previous postings about c99 floating point compliance :), I dug
around in the OSS tree and the DF/Free trees lately, investigating the
'hda' driver lately (also getting strange sounds). It seems like the
Free/DF API is a branch / modification / reimplementation of earlier OSS
code/api (released under a BSD license), but I didn't dig enough to find
that out for sure... insights welcome..

There are some mutterings on FreeBSD lists reguarding various updates
(MIDI, HDA, etc,) which it seems like df has been benefiting from as of
late, but at the same time, it's not really a priority for anyone, as it
*seems* like  most folks here and in Free-land in general are
application developers / SysAdmins, network engineers, "computer
scientists", posix conformant os fans, etc, and not as much 'music
producers' as is on the lists in #1, so the category of 'play sound' is
acceptable vs. the category of 'a real need for appropriate' audio API
for 'serious music  & sound work'

but in any case, the point of #2 is to ask:

- the 'new' OSS is released under CDDL, whereas the 'old oss' seems to
  be released under BSD

- based on the previous, is there a 'postion' w/r/t BSD licensing?

  e.g.CDDL is OK if it doesn't 'taint' the rest of the tree and the
  code would adds more functionality, or since the CDDL license is not
  100% 'do what you want', it's no good.


Overall, I-M-H-Non-Commit-Bit-O there are probably a few things
worth considering on this topic that are not all 100% technical:

  a) general licensing concerns/position of the project (CDDL vs BSD)
  b) 'purpose' of the audio subsystem (play sound vs. media production)
  c) how licensing/ purpose of the audio system relates to the overall
     goals of the project
  d) how that relates to compatibility / maintinance, etc. (e.g. right
     now, not so hard to synch with freebsd, but might mean less drivers
     w/r/t opensound, etc)
  e) the general result of OSS relicensing on the LAD / various other
     sound processing communities, and how that in-turn affects the
     other issues
  f) what the other BSD systems do in response (esp. freebsd)

In any case, this discussion is all theory if no-one is there to do the
work of porting / not porting, etc, but just thought I'd add my .25 (if
not worth that much in qty, in volume :) to the discussion... which
should perhaps move to users@ :)


- Chris

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]