Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

6 participants
7532 discussions

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

by Pedro Lopez-Cabanillas

Good hack, Clemens! > 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 > <http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html >>. > > 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. As Fernando said, it works. I have a Midisport2x2, but I don't need the Midiman's firmware, because my Midisport2x2 works very well with ezusbmidi firmware by Lars Doelle, but this can be useful for 4x4 and 8x8 owners... while there is not a better GPL solution. BTW, the latest midisport GPL firmwares and sources are available at linux-hotplug project CVS repository: http://sourceforge.net/cvs/?group_id=17679 (modulename "firmware") Regards, Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com

23 years, 2 months

[linux-audio-dev] LADSPA output controller?

by Mario Lang

Hi. I've been thinking about what could make LADSPA more fun, and I think its time for a little analog step sequencer. If I make it behave like a real analog step sequencer, Ill need a frequency output and a trigger output. Problem is, vcf303 for instance takes a controller as trigger. So I'd need to connect a audio/controller output to a controller input of another LADSPA plugin. Do ladspa hosts like ecasound support this? Or am I taking a completely wrong route here and it should be done differently? -- CYa, Mario

23 years, 2 months

RE: [linux-audio-dev] image problem

by Andrew W. Schmeder

<quote who="Mark Knecht"> > I do not see how a company could afford to invest in this area, short of > staying closed-source. Very difficult for them, so no wonder there are few companies calling Linux developers. Another difficulty with the GPL its somewhat sketchy legal basis. (OT for LAD... Google if you want to know more). 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. --- Andrew W. Schmeder

23 years, 2 months

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

by 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!

23 years, 2 months

[linux-audio-dev] Who maintains vkeybd?

by 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 <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

23 years, 2 months

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

by Patrick Shirkey

Len wrote: >> >If you will be making money from a Linux-based product, then you >> >*should* be investing your own money for promotion. >> >> I am. What's your point? >Other people (people who are not in business) need not and likely won't >invest money to promote Linux Audio. >People here invest their time and effort (but usually not money for >promotion), mostly because they're techies who want to to build >something that they really need/want. Businesses invest money for >another reason, because they want to develop and promote commercial >products. They're mostly two different worlds (though there is >crossover). Would you agree that the commercial side of Linux Audio development is not currently showing much support for the community then? Would you consider it to be partly (if not largely) because there is an image problem. >> I have a small business and there are others out there in similar >> positions. We don't have the financial resources to fund large scale >>ad campaigns on our own. But we do if we work together. >Perhaps there's no need to promote Linux Audio; perhaps instead there >is a need to promote useful products. If those products happen to need >Linux (and ALSA & Jack) as a foundation, then Linux will get promoted >as a side effect of successful products. Much like MacOS. >So if you want Linux Audio to be promoted, either make broadly useful >products or assist the companies that want to turn your work into >broadly useful products. Are you making an offer? ;) While trawling then net today looking at the google search on the word "sound". I saw your site was listed in the first few pages. That's some tough competition there. If we had a community run organisation that lead by example do you think it would make you feel more motivated to promote Linux as a platform to your customers? Esp. If you could show them that your company has an active part in supporting the community? Eg. Official status in the form of certification or advertising space, naming rights, awards in your honour... BTW. Would you like to add your Company to the Tech Support database? http://www.djcj.org -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

23 years, 2 months

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

by 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-<target>/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!

23 years, 2 months

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

by Tim Goetze

pleased to announce another ladspa unit - 'preamp'. this plugin implements an amplitude response that has been obtained from a spice simulation of the preamp stage of a modified fender 5F4 instrument amplifier. http://quitte.de/dsp/preamp.html tim

23 years, 2 months

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

by 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

23 years, 2 months

Re: [linux-audio-dev] Gigasampler vs Halion PR war

by Juhana Sadeharju

>From: Paul Davis <paul(a)linuxaudiosystems.com> > >idea, wrapped it up in patent language that restricts it to a specific >problem domain (playback of audio data in response to triggers), and >filed. There has been "instant play" devices prior gigasampler. I also found following from Usenet archives. I also have a product adv which can be used as directly-from-disk MIDI sampler with fades; I will scan and place this adv available soon. Year is 1990. Juhana ==cut== >> Forum: rec.audio.opinion Subject: Re: Why buy a digital transport? Date: 04/12/1995 Author: Mark Brindle <brindle(a)lf.hp.com> [ cut ] : a totaly error free transport system which would alow random play and : near ( sub 10ms ) access to any audio on the cd-rom ?? You've just described a hard-disk recorder. But, if you want to save some money, and you don't plan to edit the music, you could get by without the hard drive. Substitute a few megs of RAM; and if you need *INSTANT* access, cache the first second of every "cut" in memory -- then, you could start playing any track with only a few microseconds delay. Of course, anything quicker than about 50ms seems instantaneous to mere mortals. ...it's "only" software, Mark ==end==

23 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev