Re: [linux-audio-dev] Please test my MidiSport firmware loader

[Fernando Pablo Lopez-Lezcano]

> I've created a package which extracts the firmware for MidiSport devices
> from the Windows driver files and installs the hotplug script to download
> the firmware. You can get it at
> .
> 
> There are some differences to Lars Doelle's GPL firmware:
> - it supports MidiSport 4x4/8x8/Keystation/Oxygen
> - no configuration file editing, just 'make install'
> - it requires ALSA because the Midiman firmware doesn't conform to the USB
>   MIDI specification
> 
> I don't have a MidiSport device, so this is completely untested.

GREAT!!! It works!

Just tried it with current alsa cvs and the firmware loads and alsa
likes it (well, almost, I still have problems with sequencer playback
from muse, I have to try rebuilding muse from scratch). 

I tested it with an Oxigen8 and a Midisport 2x2. Do you happen to know
if the Midiman Quattro midi interface could use this method as well?

Now I have to create packages for all this :-)
-- Fernando

RE: [linux-audio-dev] image problem

[Kai Vehmanen]

On Wed, 13 Nov 2002, Mark Knecht wrote:

>Let me ask another question in this area. Could someone explain the
> implications of GPL/LGPL WRT proprietary applications that interface to Alsa
> & Jack, along with their incumbent support programs like kaconnect and
> qjackconnect?

Both ALSA (alsa-lib, ie. libasound) and JACK (libjack) are licensed under 
LGPL and thus allow their use even from proprietary applications.

Btw; ecasound's control interface (EC) is licensed under LGPL (recently
 changed), so it's possible to write closed-source apps that use
 ecasound as the audio engine. Other parts of ecasound are
 still under GPL, so if you want to improve or extend the audio
 engine, you'll have to release your changes under GPL.

>If Jack and Alsa were pushed in technical business development circles as
> a way for Company A to enter the Linux market and be able to work together
> with other existing applications, do the GPL/LGPL licenses of Alsa & Jack
> create issues for Company A's proprietary code base?

No. Glibc is also LGPL licensed, so if there were any problems with using 
LGPL libraries from closed-sourced apps, this would affect _all_ 
applications that run on Linux.

>I see the open nature of Linux as best exemplified in the lower level
> portions of the audio stack, and less so at the application level for the
> reasons we've been discussing. As a person who is in business, but not in
> this area, I have suspicions that these are the issues that are keeping
> retail applications out of the Linux markets.

At least I wouldn't mind if some commercial entity used ecasound in their
product. I would get improvements and fixes to the engine code and they
could keep the interface to themselves. I'm fully content using the
user-interfaces that are already available for ecasound, so this would be
a win-win situation for me. Of course, a completely different thing is
whether anyone wants to use ecasound...:)

-- 
 http://www.eca.cx
 Audio software for Linux!

Re: [linux-audio-dev] image problem

[Paul Davis]

>   Let me ask another question in this area. Could someone explain the
>implications of GPL/LGPL WRT proprietary applications that interface to Alsa
>& Jack, along with their incumbent support programs like kaconnect and
>qjackconnect?

alsa-lib is LGPL'ed, as is libjack. proprietary software can use these
libraries with no implications for their own code. if they choose to,
or need to, make changes in the LGPL'ed library code, those changes
must be made available under the LGPL.

>   If Jack and Alsa were pushed in technical business development circles as
>a way for Company A to enter the Linux market and be able to work together
>with other existing applications, do the GPL/LGPL licenses of Alsa & Jack
>create issues for Company A's proprietary code base?

not unless they have lawyers who don't understand this stuff.

>   I see the open nature of Linux as best exemplified in the lower level
>portions of the audio stack, and less so at the application level for the
>reasons we've been discussing. As a person who is in business, but not in
>this area, I have suspicions that these are the issues that are keeping
>retail applications out of the Linux markets.

a web page on the ardour site says:

  "Your participation in the development and use of Ardour can help
  bring to the audio world the same kinds of benefits that open source
  development have accrued to the world of web servers. The most
  widely use web server ("apache") contains code written by hundreds
  if not thousands of people, and has been subject to continual
  evolution and improvement. By contributing cash, comments, insight,
  code, feedback or even just enthusiasm, you will help keep the
  project moving forward towards a day when the best DAW is open for
  everyone to study, improve and most of all, use and enjoy."

*that's* what "open" means to me. i don't care how good ProTools (or
Nuendo or Paris or ...) is - i could always find ways to make it
better if i had the source code. the same applies to almost ever other
proprietary audio software out there (1).  but i can't get the source
code, so part of the promise of what we are doing here is to create
the necessary cultural artifacts necessary to move at least some
significant chunk of the audio software field towards this kind of
"open".

yes, it will be very hard to make (significant) money via traditional
retail channels with this sort of stuff. thats OK, i think.

--p

(1) there are a few exceptions. a recent one might be the Native Instruments'
FM7, which strikes me as just about perfect in every way. 

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

[Kai Vehmanen]

On Wed, 13 Nov 2002, Paul Davis wrote:

>>my conclusion is that the level of atomicity provided by 
>>linux asm-arch/atomic.h is not needed to implement 
>>single-reader-single-writer lock-free buffers.
> this is true unless the pointer/index isn't atomic. since on SMP sparc
> systems, the arrangement of the cache lines means that you can't
> guarantee better than 24 bit atomic values, you do have to be careful
> about the potential size and memory position of the pointer/index
> variables. 

I've browsed through the sparc arch manuals and couldn't find anything 
that would limit atomic access to 24 bits nor any directly related cache 
line limitations. The Linux asm-sparc/atomic.h provides only 24bits as 
it uses the lower 8bits to implement a low-overhead spinlock. Spinlock
is required to guarantee memory ordering (also with mixed usage of
various atomic_* ops). If you just read/write 32bit ints, this is
atomic even on SMP-sparcs.

>>in handling the l-f buffer indices. In the worst case 
>>reported write-space is larger, or read-space smaller, 
>>than the actual situation.
> actually, the worst case for both metrics is that they are *smaller*
> than they should be. this happens on two occasions:

Ugh, true, my mistake.

> its not so much "atomicity" as "ordered" that is needed here.  because
> read/write will only use that part of the buffer indicated as
> available by the r/w pointers, all we have to know is that the writes
> to the buffer complete before the write pointer is updated. it would
> be good to use a so-called "memory barrier" somewhere there to make
> sure this is true.

Ok, this is a real problem, but I don't think using asm-arch/atomic.h
(which can guarantee ordered access to the buffer indices) helps 
to solve this issue, so you might just as well use regular ints 
as the atomic indices.

And this really is a corner case as the buffer would have to be close to 
empty (something has already gone wrong!) to read old data from the 
buffer, even on a SMP sparc or s390.

--
 http://www.eca.cx
 Audio software for Linux!

RE: [linux-audio-dev] image problem

[Mark Knecht]

Hi,
   To be clear, I was in no way suggesting that I thought Paul should change
his licensing terms in any way. I'm just interested in exploring the
underlying reasons why there are not more Linux applications available at
the retail level.

   I personally think that this topic is interesting and enlightening. It is
(in some small way) about Linux Audio because we can discuss audio
applications. If people want this to go off line or can suggest a better
forum, please speak up.

   Let me ask another question in this area. Could someone explain the
implications of GPL/LGPL WRT proprietary applications that interface to Alsa
& Jack, along with their incumbent support programs like kaconnect and
qjackconnect?

   If Jack and Alsa were pushed in technical business development circles as
a way for Company A to enter the Linux market and be able to work together
with other existing applications, do the GPL/LGPL licenses of Alsa & Jack
create issues for Company A's proprietary code base?

   I see the open nature of Linux as best exemplified in the lower level
portions of the audio stack, and less so at the application level for the
reasons we've been discussing. As a person who is in business, but not in
this area, I have suspicions that these are the issues that are keeping
retail applications out of the Linux markets.

Thanks,
Mark

-Original Message-
From: [EMAIL PROTECTED]
[mailto:linux-audio-dev-admin@;music.columbia.edu]On Behalf Of Paul Davis
Sent: Wednesday, November 13, 2002 8:09 AM
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] image problem


>Another difficulty with the GPL its somewhat sketchy legal basis.  (OT for
>LAD... Google if you want to know more).

the GPL is a contract freely entered into by the copyright owner and
the licensee. if the contract is held to be invalid, there is no
contract. at that point copyright law denies everyone except the
copyright holder any rights (except fair use) regarding the copyright
work.

i suppose you could call this sketchy. or not. ymmv.

>I've noticed that Dual licencing GPL/Commercial seems to fit in with the
>corporate mindset, however.  (e.g. Mysql).  Ardour/Libardour could go this
>route if all the developers desired it.

unlikely, but not impossible.

--p

Re: [linux-audio-dev] Who maintains vkeybd?

[Dr. Matthias Nagorni]

On Wed, 13 Nov 2002, Mario Lang wrote:

> So I'd like to get this mod out there somehow, but
> the authors email of vkeybd does no longer work...

vkeybd has been written by Takashi Iwai. His email is [EMAIL PROTECTED]

Matthias

-- 
Dr. Matthias Nagorni
SuSE GmbH
Deutschherrnstr. 15-19phone: +49 911 74053375
D - 90429 Nuernberg   fax  : +49 911 74053483

Re: [linux-audio-dev] image problem

[Paul Davis]

>Another difficulty with the GPL its somewhat sketchy legal basis.  (OT for
>LAD... Google if you want to know more).

the GPL is a contract freely entered into by the copyright owner and
the licensee. if the contract is held to be invalid, there is no
contract. at that point copyright law denies everyone except the
copyright holder any rights (except fair use) regarding the copyright
work.

i suppose you could call this sketchy. or not. ymmv.

>I've noticed that Dual licencing GPL/Commercial seems to fit in with the
>corporate mindset, however.  (e.g. Mysql).  Ardour/Libardour could go this
>route if all the developers desired it.

unlikely, but not impossible.

--p

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

[Paul Davis]

>Also, with much of the audio/desktop stuff still under development, I 
>experienced much less of the linux/server stability...
>
>Some months ago, the alsa driver would freeze my system whenever I tried 
>to use the sequencer interface. More recently, the dri-driver for my 
>radeon keeps doing the same. Then again my KDE-desktop is rendered 
>unusable from time to time by some buggy apps not to mention all the 
>beta audio-applications which aren't stable yet.
>
>So right now, I think stability is not really an argument pro linux 
>audio.

the argument for stability is not a general claim about all drivers
and all software. its an argument about how a properly configured
linux system will behave. yes, there are lots of flaky applications
around (i wrote some of them :), and several problems with various
device drivers. however, such things exist in the world of proprietary
OS's as well. what we have that they don't (except OS X) is a baseline
stability that is, well, by most standards its completely
amazing. when i explain to people that the machine in my office stays
up for months at a time, even when i am doing active software
development on it (not device drivers :), they look completely
amazed. they just can't imagine that a computer could do such a
thing. now, if go and install the latest ALSA from CVS, i could blow
things out of the water. this is where skills, expertise and the rest
come in. its not simple to set up *any* computer with *any* OS for use
in a professional audio context. you have to know about minor interactions
between apparently unrelated bits of hardware, odd bits of software
and sysconfig arcana - its basically an area that most users shouldn't
tackle. carillon seems to be doing reasonably well selling its
pre-built systems in the UK precisely because of this reason, and i
see no reason why the linux end of things will be any different.

--p

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

[Paul Davis]

>Actually I've spent some time studying this issue and 
>my conclusion is that the level of atomicity provided by 
>linux asm-arch/atomic.h is not needed to implement 
>single-reader-single-writer lock-free buffers.

this is true unless the pointer/index isn't atomic. since on SMP sparc
systems, the arrangement of the cache lines means that you can't
guarantee better than 24 bit atomic values, you do have to be careful
about the potential size and memory position of the pointer/index
variables. 

>More specifically, asm/atomic.h provides guaranteed 
>ordering of reads and writes. This is not really needed 
>in handling the l-f buffer indices. In the worst case 
>reported write-space is larger, or read-space smaller, 
>than the actual situation.

actually, the worst case for both metrics is that they are *smaller*
than they should be. this happens on two occasions:

 1) the write thread has written more data, but has
  not yet updated the write pointer.

 2) the write pointer has advanced the write pointer,
  and it has gone "beyond" the end of the buffer.
  the pointer will be "folded" back to the
  start of the buffer, but this hasn't happened yet.  

the situation is symmetric for the read side of things.

>The only problematic scenarios are that a) read returns
>an invalid value, and b) write stores an invalid value. 
>These could possibly happen if reads/writes were not
>atomic. 

its not so much "atomicity" as "ordered" that is needed here.  because
read/write will only use that part of the buffer indicated as
available by the r/w pointers, all we have to know is that the writes
to the buffer complete before the write pointer is updated. it would
be good to use a so-called "memory barrier" somewhere there to make
sure this is true.

--p


 But so far I haven't found any platforms (with
>publically available specs) which don't guarantee this 
>level of atomicity (even in the case of complex processor 
>cache arrangements).
>
>The two architectures for which asm-xxx/atomic.h contains 
>special code even for plain reads and writes are SMP-sparc
>and s390. I haven't studied s390, but at least in the case 
>of sparcs (ref: sparc v8 arch manual), reads and writes are 
>atomic even in a SMP configuration, although ordering is not 
>guaranteed. More specifically, if TSO (Total Store Ordering) 
>memory mode is selected, loads do not necessarily appear in 
>order. If using PSO (Partial SO), stores as seen by the
>issuing processor can be executed out-of-order. But these
>restrictions aren't really a problem for l-f buffers.
>
>If I've interpreted the situation incorrectly, or someone
>has better information, I'd be very interested to know! 
>Even better, example code that demonstrates atomicity
>problems... I have currenly access to both IA32 and 
>Sparc-v8 multi-processor machines.
>
>-- 
> http://www.eca.cx
> Audio software for Linux!
>
>
>
>---
>This sf.net email is sponsored by: Are you worried about 
>your web server security? Click here for a FREE Thawte 
>Apache SSL Guide and answer your Apache SSL security 
>needs: http://www.gothawte.com/rd523.html
>___
>Jackit-devel mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jackit-devel
>

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

[Len Moskowitz]

"Richard Bown" <[EMAIL PROTECTED]> wrote:

> > I don't know about "many" but it's happened to me.  I've looked for
> > software engineers to assist in developing a Linux-based audio
> > product and had difficulty finding development/consulting help.  And
> > this was for a funded project.
> 
> Yeah so you keep on saying but when I send you an email saying "Ok then, 
> let's talk" you don't reply.  Technical reason or justifiable paranoia?

Just to close off this part of the thread: Richard and I finally connected.


Len Moskowitz
Core Sound

[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization

[Kai Vehmanen]

Btw; I'll cc'd this to lad, as this is a topic that 
 has been discussed there _many_ times. More 
 specifically the SMP-sparc case has been mentioned
 quite a few times but without specific details.
 For lad-only readers, see the jackit-devel archives
 for the whole thread.

On Wed, 13 Nov 2002, Tim Goetze wrote:

> it should be noted that this relies on accesses to the
> r/w buffer indices to be atomic. that's no problem on 
> common workstation hardware, though.
[...]
> /usr/src/linux/include/asm-/atomic.h gives more
> info.

Actually I've spent some time studying this issue and 
my conclusion is that the level of atomicity provided by 
linux asm-arch/atomic.h is not needed to implement 
single-reader-single-writer lock-free buffers.

More specifically, asm/atomic.h provides guaranteed 
ordering of reads and writes. This is not really needed 
in handling the l-f buffer indices. In the worst case 
reported write-space is larger, or read-space smaller, 
than the actual situation.

The only problematic scenarios are that a) read returns
an invalid value, and b) write stores an invalid value. 
These could possibly happen if reads/writes were not
atomic. But so far I haven't found any platforms (with
publically available specs) which don't guarantee this 
level of atomicity (even in the case of complex processor 
cache arrangements).

The two architectures for which asm-xxx/atomic.h contains 
special code even for plain reads and writes are SMP-sparc
and s390. I haven't studied s390, but at least in the case 
of sparcs (ref: sparc v8 arch manual), reads and writes are 
atomic even in a SMP configuration, although ordering is not 
guaranteed. More specifically, if TSO (Total Store Ordering) 
memory mode is selected, loads do not necessarily appear in 
order. If using PSO (Partial SO), stores as seen by the
issuing processor can be executed out-of-order. But these
restrictions aren't really a problem for l-f buffers.

If I've interpreted the situation incorrectly, or someone
has better information, I'd be very interested to know! 
Even better, example code that demonstrates atomicity
problems... I have currenly access to both IA32 and 
Sparc-v8 multi-processor machines.

-- 
 http://www.eca.cx
 Audio software for Linux!

Re: [linux-audio-dev] [ann] preamp.so

[Tim Goetze]

Lamar Owen wrote:

>On Tuesday 12 November 2002 09:49, Tim Goetze wrote:
>> more interesting is that if you feed it a sine wave, the
>> circuit *never* clips the lower lobe, it rather seems to
>> compress so the lower lobe never hits the end of the curve.
>> it does clip the lower lobe of a triangle however.
>
>This is interesting.

i'd like to understand why, but in the meantime implementing
similar behaviour is not that hard. :)

>So the SPICE sims have helped.  Great!  I know that SPICE is the cat's meow 
>for electronic/electrical design problems, which is where I've used it in the 
>past.  It's just not quite fast enough to do real-time effects processing, 
>even on current hardware.

yep, it's a great program, and in true grand old unix spirit, 
it hides behind an unfriendly and fiendish interface. ;)

judging from execution times on this box, you'd probably need 
something like a recent 32-way cluster to run a whole amp sim 
in realtime. 

tim

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

[Christian Henz]

On Tue, Nov 12, 2002 at 09:48:00PM -0500, David Gerard Matthews wrote:
> 
> D R Holsbeck wrote:
> 
> >I guess stability is not an issue? 
> >
> It's not the potential drawing card that it once was.  OSX is as stable 
> as Linux, and even 'doze XP is getting there, from what I hear.
> -dgm
> 
Also, with much of the audio/desktop stuff still under development, I 
experienced much less of the linux/server stability...

Some months ago, the alsa driver would freeze my system whenever I tried 
to use the sequencer interface. More recently, the dri-driver for my 
radeon keeps doing the same. Then again my KDE-desktop is rendered 
unusable from time to time by some buggy apps not to mention all the 
beta audio-applications which aren't stable yet.

So right now, I think stability is not really an argument pro linux 
audio.


cheers,
Christian Henz

[linux-audio-dev] Who maintains vkeybd?

[Mario Lang]

Hi.

Yesterday I hacked a bit on vkeybd, and managed
to turn the vkb.c into tclkvb.so, such that I now
can do 

$ tcl
tcl% load "./tclkvb.so"

and use the tcl commands like

SetDevice midi
set mididev 0
SeqOn
...

and so on.

This basicly means we could write tcl scripts which use the vkeybd
backend, without having to use tk. Or even write different
frontends...

So I'd like to get this mod out there somehow, but
the authors email of vkeybd does no longer work...

-- 
CYa,
  Mario | Debian Developer http://debian.org/>
| Get my public key via finger [EMAIL PROTECTED]
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

[linux-audio-dev] [ANN] ALSA Patch Bay 0.3

[Bob Ham]

Hi all,

I'm in a hacking mood :)  I added an fltk (1.1) interface to alsa patch bay,
and also updated the gtkmm interface to use 2.0.0.  It can use both, or just
one.  Tarball here:

http://pkl.net/~node/software/alsa-patch-bay-0.3.tar.gz (214KB)

I also made a spiffy (if sparse) page for it here:

http://pkl.net/~node/alsa-patch-bay.html

Have fun,

Bob

Re: [linux-audio-dev] LADSPA output controller?

[Steve Harris]

On Wed, Nov 13, 2002 at 12:42:31 +, Dave Griffiths wrote:
> A LADSPA tracker may be stretching the "simple" factor slightly, but it
> would be a fun project (and ahem, SSM needs a tracker badly!)

Steve starts singing the jack song.

- Steve

Re: [linux-audio-dev] LADSPA output controller?

[Steve Harris]

On Tue, Nov 12, 2002 at 06:09:20 -0800, Paul Winkler wrote:
> On Wed, Nov 13, 2002 at 12:42:31AM +, Dave Griffiths wrote:
> > Can you open files in a LADSPA plugin?
> 
> don't know, but you can't pass strings to a LADSPA plugin's ports,
> so getting the filename in would be ... interesting.

Yeah, been there. I came to th econclusion that if it needed string
arguments then it wasn't really LADSPA-ey enough.

- Steve