As in, how do I share my own? What licenses or other scheme do you all
use for music that you create and would like to be widely distributed,
with or without any other restrictions. What considerations do you take
into account?
disclaimer: I don't have any cool music to release (yet), although I have a
few almost-cool works for the extremely curious...
--
Hans Fugal | De gustibus non disputandum est.
http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg
http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
Hello,
I have been unsubscribed from alsa-devel for a while, so maybe i missed
the discussion about this, but a quick look at the archives did not reveal
anything.
I just downloaded alsa 1.0.0rc2, and discovered that the API changed.
For example (and this is only an example), take the function
snd_pcm_hw_params_set_rate_near. Before, the 3th argument was the
samplerate requested, and the return value was the error value (<0) or
the samplerate obtained.
err = snd_pcm_hw_params_set_rate_near(handle, params, rate, 0);
Now, the third argument is a _pointer_, used to pass the requested value
_and_ to return the obtained samplerate. Note that the symbol is
identical, and that an application compiled against the old version will
happily link against the new version (but surely fail when executing!)
(or am I missing something here??)
I clearly see the advantage of the new, cleaner, approach, but I still
remember the past ALSA API changes, and I was under the impression that
that would not happen again. I also thought that the 0.9.x releases were
a straight line to work towards the 1.0 release. So I am very surprised
to see this happen. If this has been discussed / announced somewhere,
than I am sorry for having missed it, but in any case, I think it might
be good to place a notice on the alsa web page.
Maarten
Here is the realtime LSM version 0.0.2, for use with 2.6 kernels.
-- New features
- mlock parameter enables memory locking privileges
- allcaps parameter enables all capabilities, including CAP_SETPCAP
- restores cap-bound on exit
-- Makefile improvements
- use security/commoncap.c from the kernel sources
- make dist
-- Documentation
- README explains options
- INSTALL instructions
- COPYING file for GPL
--
joq
Hi,
tisdagen den 09 december 2003 12.22 skrev Steve Harris:
> On Tue, Dec 09, 2003 at 09:25:42AM +0100, Clemens Ladisch wrote:
> > > > I seem to recall that it does, but that the packet size is smaller,
> > > > making the latency problem easier to deal with.
> > >
> > > Isoch - 1394 has a timer operating on the bus. This timer happens
> > > (roughly) every 125uS.
> >
> > USB isochronous transfers happen once per millisecond.
>
> OK, so its the difference between 44 or 45 samples per packet at 44.1kHz
> (USB) and 5 or 6 (1394).
>
> So, a plausible jack period of 64 samples will be 11 or 12 1395 packets,
> but always 125uS of jitter of course, (10 or 11 packets at 48k).
>
> I dont really have any idea how bad that is, its 8% of the availble time
> slot for processing the 64 samples.
>
> You could lessen the effect of the jitter by having triple-buffering in
> software, as in a 3x64 PCI soundcard - I dont know wether thats better
> than just going to 128 samples or not.
>
> FWIW, for my needs I rarely go below 256 samples/period anyway, even
> though my setup is capable of it, but I understand there are people who
> really need very low latency.
>
> At 256 samples/period the jitter is only 2.1% of the time slice, which is
> unlilkly to matter - cache temperature and so on has a far greater effect
> than that.
Though it is interesting debating the technical merits of firewire, for me,
atleast, it would be far more interesting to get it actually working. I'm
_very_ interested in utilizing these hardwares.
I googled a little last night, some people we all know popped up here and
there (Hi Steve, Mark and Bob).
There was a LAD message from 2001, someone who had been in contact with Yamaha
and it seemed they(Yamaha) where working towards making mLan a part of the
A&M standard (I think I got that right...not sure)... now... I'm not entirely
sure what this means. It seemed as the A&M standards also cost a lot of
money?
Do we have enough information to implement mLan support?
As I understand it, Bob Ham had/is working on implementing 61883 support for
Jack, which seems like it's needed for mLan, a layer below it perhaps? How
far has this come, is there something one can test somehow, what hardware do
one need?
Regards,
Robert
ps.
I'm cc:ing LAD as I'd like to move the discussion there. Remove LAU if you
respond to this.
ds.
On Martes, 09 de Diciembre de 2003 10:57, Gerrit Niestijl wrote:
> Hi,
>
> When i use timidity in alsa seq mode with a sequencer like muse or
> seq24, the timing is not very good. If i use fluidsynth the
> timing is much better. I would like to use timidity though, because
> of its support for the Midi Tuning Standard.
>
> Are others seeing this too? Are there any options or
> other ways to improve the timing for timidity?
try to start timidity with: -B2,8
Josep
hello linux audio enthusiasts!
reading lwn.net this morning i found that the linux journal has a new
linux audio column in their online edition, written by dave phillips.
the current issue is at
http://www.linuxjournal.com//article.php?sid=7283 .
the content of this first issue will not be news to you, since it's
basically a plug for the world's finest linux audio mailing lists, which
you already seem to know about :)
still, it's an interesting read, and it has had an effect already: about
30 new subscriptions (in addition to the usual continous growth) since
wednesday... (see http://www.linuxdj.com/audio/lad/subscribe.php3 .)
to all new readers: welcome aboard!
best,
jörn
--
To someone whose only tool is a hammer, each problem looks like a nail.
- Edsger W. Dijkstra, EWD838
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
Hi all
I haven't really been following the discussion about the capabilities
patches etc, so bare with me if I have missed anything.
I am currently preparing an updated kernel, and am wondering whether any of
the proposed patches for a 2.4 kernel are stable enough to be usable. If
so, where can I obtain the patches?
Thanks
Luke
--
Luke Yelavich
AudioSlack Founder and head package maintainer
Audio software packaged for the Slackware Linux Distribution
http://www.audioslack.com
luke(a)audioslack.com