Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

Re: why open source drivers [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Marek Peteraj

On Sun, 2004-11-28 at 21:31, Mark Knecht wrote: > On Sun, 28 Nov 2004 15:20:33 -0500, Lee Revell <rlrevell(a)joe-job.com> wrote: > > On Sun, 2004-11-28 at 12:06 -0800, Mark Knecht wrote: > > > > > > > > Fine with me. If I shelled out for RME hardware I better be able to > > > > call RME for support, same as on any other OS. You get what you pay > > > > for, right? > > > > > > Sure, but when you buy it and the box says 'Requires Mac OS X or > > > Windows XP' then as a buyer I have to respect that. I cannot expect > > > them to support Linux when it wasn't advertised that it works on > > > Linux. RME has given me GREAT support under Windows and I expect that > > > this will not change. They are a great company. I own two cards and > > > wouldn't hesitate to buy another if I was going to set up another > > > Windows box. > > > > Yeah, I was referring to an Nvidia like scenario, where they don't > > release open drivers, but release closed Linux drivers of comparable > > quality and the same support as the Windows driver. > > Sure, I get it. However I think you and plug in a close source RME > card driver and happily use it if it was available. I think Marek, > Frank and others do not feel this way. I had no second thoughts about > putting an NVidia controller in my dad's Linux box even though I used > ATI up until then. My experience using both is no that different, but > for me it's not political. > > Am I wrong when I think this desire is particularly European in > nature? I'm so Open Market driven, especially when it comes to > technology, that I hardly seem to understand this oter POV. However, I > am interested. One nice example. Korg 1212 i/o, worked under win98, doesn't under winXP because korg does not provide support for it. There is an alsa driver for it now(and specs), so basically the life of that card is extended to eternity. There are more such damn good reasons for open source drivers. People just don't shout too loud. :) > > > > > Of course I would be pretty annoyed if they just drop Linux completely, > > for the same reasons as others in this thread - they have a relationship > > with the community at this point. But I don't think they would be that > > stupid. After all pissing off hundreds of potential customers is just > > as bad an idea as giving valuable IP to the competition. > > > > Darn straight. However how did Marek end up being an RME customer when > there was (as far as I know) never any support for this device under > Linux, nor anyone even really saying there would be? Actually not quite, it seemed as if there would be support, Thomas wanted to do the driver. I just invested too much trust in RME. My fault. > In my case I Was > told that supporting the HDSP 9652 would be a non-issue based on the > DigiFace working. It turned out to be true, but then again it took > about a year to become really useful to me, and even today doesn't > work as well as it does under Windows. How did he end up with this > device and in this position? > > I somehow don't think this is RME's fault... If RME did the drivers for your HDSP 9652 then you could directly contact them and ask them for support. I'm sure Thomas would help you aswell if he had the card, and that's the problem. In such case claiming that they do support alsa is just plain unfair. Marek

20 years, 6 months

[linux-audio-dev] Tastes like chicken!

by John Check

I haven't posted anything in a while, but I'm sure some of you remember I made a few claims over the summer. Fear not, things are moving along. Anyhoo, I had a spark of inspiration and banged out a little sort of folk tune tracked with ardour. Audacity as a front end for LAME. Still getting my ears calibrated to a subpar monitoring system so forgive the buried vox and any tubbyness. 4 tracks. 1 scratch guitar & vocal (the limiting factor) 1 bassline 1 vox overdub 1 keyboard http://65.125.227.61 click the title header for a link l8r J

20 years, 6 months

[linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

by Simon Jenkins

Hi all: I've been thinking some more about a prototyping/development board (not a production board) for a free open multi-channel firewire audio interface. The objective would be to keep initial development time and costs down even at the expense of pushing component costs slightly up. Here are my very rough, version 0, not-fully-thought-out thoughts: ~ Use off-the-shelf asics for the firewire link and physical layers ~ Use a small-ish xilinx spartan 3 fpga for the rest of the "signal path" logic ~ Use a microchip dsPIC for everything that's off the "signal path" ~ Leave A/D, DA converters (or dig audio I/O) etc entirely off the board: Just provide headers for adding them on a sub-board later. There's a block diagram here: http://www.sjenkins.pwp.blueyonder.co.uk/fwboard/block01.png Some notes: 1. The smaller spartan 3 fpgas are supported by the free, downloadable ISE WebPACK software. 2. The PCI block in the fpga doesn't need to be that fancy or versatile. It just needs to handle the one TI component fast enough to get data in and out of its FIFOs on time plus the occasional (much less time-critical) interactions between the dsPIC and the link layer. It doesn't need to do this stuff as fast as possible - there's nothing else on the PCI bus to contend the bandwidth - it just needs to do it fast enough. 3. The dsPIC never, ever touches the audio data. The converter interface engine directly handles all transfers between the link-layer fifos and its own buffering. It also directly handles any other time-critical interactions with the link layer. 4. The dsPIC does everything else: It... ~ stores and programs the fpga configuration data ~ performs all non-time-critical interactions with the link layer and, via the link layer, with the driver. ~ initialises the converter interface engine ready for whatever formats of audio I/O may be about to start ~ stores user configuration data ~ handles any LEDS, switches, pots, encoders, LCDs or whatever might go on an interface front panel. ~ does any non-time-critical control of an analog I/O subboard. (eg if analog monitoring were implemented the dsPIC would do the necessary switching). ~ could handle a first-cut implementation of MIDI, although this might better be migrated to the fpga. Comments? Cheers Simon

20 years, 6 months

[linux-audio-dev] [ANN] Hydrogen v0.9.1

by Comix

I'm proud to announce a new stable release of Hydrogen Drum Machine!! Features: __General__ * Very user-friendly, modular, fast and intuitive graphical interface based on QT 3. * Sample-based stereo audio engine, with import of sound samples in .wav, .au and .aiff formats. * Support of samples in compressed FLAC file. __Sequencer and mixer__ * Pattern-based sequencer, with unlimited number of patterns and ability to chain patterns into a song. * Up to 64 ticks per pattern with individual level per event and variable pattern length. * 32 instrument tracks with volume, mute, solo, pan capabilities. * Multi layer support for instruments (up to 16 samples for each instrument). * Ability to import/export song files. * Unique human velocity, human time and swing functions. * Multiple patterns playing at once. __Other__ * JACK, ALSA and OSS audio drivers * ALSA MIDI input with assignable midi-in channel (1..16, ALL). * Import/export of drumkits. * Export song to wav file. * Export song to midi file. Changes: * New ALSA driver * New french tutorial and manual page (thanks to Pierre 'AlSim' Chapuis) * Bug fix Download: http://hydrogen.sourceforge.net Vote hydrogen at the italian open source contest! http://hydrogen.sourceforge.net/HowToVote.html Happy drumming! :^) -- Alessandro <Comix> Cominu http://hydrogen.sf.net e-mail: comix(a)despammed.com Icq: 116354077 Linux User # 203765

20 years, 6 months

[linux-audio-dev] GNU Common C++ 1.3.0, new ccAudio2 0.1.0, ccrtp 1.1.2 released this morning

by David Sugar

Along with Common C++, I also made available the first release of the new and much improved stand-alone (no longer requires GNU Common C++) version of the GNU Common C++ Audio class framework; "ccaudio2". This new framework, in addition to being more portable and fully endian aware than it's predecessor (it builds and runs on platforms as varies as GNU/Linux, various BSD's, OSX, and W32) also includes a new stand-alone utility, "audiotool", which can do various basic manipulations with audio files, and a revised system for supporting audio codecs as plugins. ccAudio2 still needs additional work, particularly in support of .mp3 and .ogg audio containers, and in getting additional codecs working. We also had a w32 installer built using GNU GPL licensed "inno setup" builder which installs all three class libraries together, along with a new class reference manual, for those using a freedom challenged platform. The one place all these things can be found together at the moment is: http://sourceforge.net/project/showfiles.php?group_id=1523&package_id=41672…

20 years, 6 months

Re: [linux-audio-dev] ALSA OSS Emulation and emu10k1

by Peter Zubaj

Hi, AFAIK: OSS device on emu10k1 is always routed to front channels. Routing can be changed through alsa mixer api (there are controls controling channel routing), but this is not simple and there is problem to know what oss stream uses what hw stream, because these are alocated dynamicallly. Other ways will require driver change. Peter Zubaj ____________________________________ http://www.pobox.sk/ - najvacsi slovensky freemail

20 years, 6 months

[linux-audio-dev] ALSA OSS Emulation and emu10k1

by Melanie

Hi, I was wondering, is it possible to assign /dev/dspX devices to the secondary and tertiary PCM devices on an emu10k1? I have a SB Live! Platinum with LiveDrive IR. The stereo out is connected to my regular set of speakers. The surround output is connected to an earphone headset, it's mic is connected to the mic input on my sound card. Also, another microphone is connected to the mic/line on the LIveDrive. Now, I use skype, which is closed source. It uses OSS devices and aoss will not work with it. I would like to have a /dev/dspX device that records from the mic input and plays back to the surround output, so that skype, and skype only, will use the headset. The headset works fine in alsa mode and alsa apps can use it perfectly well. I tried all /dev/dspX and /dev/adspX devices, to no avail. I tries aoss with .asoundrc modifications, no luck. I even read the driver source, but I'm not really conversant with the structure of the driver and couldn't find anything useful. It would take me forever to figure it out from the source code. Is it possible, maybe with module parameters, to make alsa do this? Would it need a patch, if yes, does someone have one? If no, what would have to be done where to make that work? Melanie

20 years, 6 months

Re: Behringer [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Marek Peteraj

On Sun, 2004-11-28 at 14:03, tim hall wrote: > Last Saturday 27 November 2004 21:36, Lee Revell was like: > > On Sat, 2004-11-27 at 15:43 -0500, Lee Revell wrote: > > > > Did this happen? > > > > > > Maybe not to them but look at Mackie and Behringer. > > > > Just to save people some googling here is a thread that documents the > > long and colorful history of pro audio hardware manufacturers blatantly > > ripping each other off, often leaving the victims with no legal > > recourse: > > > > http://homerecording.com/bbs/archive/index.php/t-74439.html > > > > IMO the issue is not whether RME's concern is valid - clearly it is. > > Sorry, but arguing otherwise makes us look stupid and naive. The issue > > is how to address this concern. If that means a closed source Linux > > driver, fine. > > > > Maybe the reason no firewire hardware is supported is because Behringer > > and their ilk would instantly have all the info they need to copy the > > design and mass produce it. Doesn't matter how cheap the device is to > > design - it will _always_ be cheaper to rip someone off than design it > > yourself. They can even sell at a loss, due to huge cash reserves - > > they only need to sustain it long enough to put the competition out of > > business. In the case of the "Swizz Army Tuner", the original designers > > were ripped off by Behringer, but a lawsuit would have bankrupted them > > _even if they won_ so could not take action. > > > > I think many people in this thread underestimate how cutthroat the > > hardware business is. > > Yeah, If I was the MD of RME, after reading some of the responses on this > thread I'd be thinking of flippin' the bird at all these ungrateful linux > users. I think it's about defending the position of open source and its nature. And the work that people do here no matter whether for fun or not. >From now on every company that doesn't do it like audioscience does, is a plain loser to me, no matter whether they provide specs or not. It's because other people do the actual work + support providing. If MacOSX can have them, so can we, we have a greater marketshare. Why the heck should we *always* understand them? Why can't they understand *us*? > We're a minority group and I think the onus is on us to convince RME > to produce a driver for their firewire hardware, politely and if necessary, > via the florists ;-). OK, so closed-source drivers are far from ideal, but > better than a hole in the head. http://www.audioscience.com If they can, who can't? I can't see the difference, can anyone explain? > > It means that the drivers can't be bundled with distros and we won't be able > to provide users & developers with technical support, which is a great shame. > > However, I suspect a certain amount of well-reasoned persistence will pay off > here. Sure, our numbers on this list aren't great, but they are significant. There are many audio hw customers outside of this list (see CK's post for example, or judging form experience - somewhere on #gnome talking about rme ;) plus tons of talks on #lad - Q: "hi, what's the best card for audio under linux? A: "rme or if you don't have that much money, maudio") > > OK, _very_ few people are using firewire technology for music, up till now I'd > considered it the preserve of mac/motu users. I think a majority of pc based audio hw will be fw based in the near future. Every manufacturer will have at least one product. Scary. > I think we should continue to > support RME where licenses allow and look forward to the day that they > release their firewire drivers :-). That is going to be the day their hw becomes redundant on the market? Or even discontinued? That's the problem i'm seeing. > I think we should keep up the pressure on > manufacturers like MOTU too. They'll see sense eventually. ;-] I doubt it. They have their own sw products, like the DP. In their case i can pretty much understand why they don't do that if they see linux audio as a competition. > > Mine is an equally naive viewpoint, but with the knowledge that a little bit > of positive thinking can go a long way, especially when backed up with a > well-researched wish-list and plenty of patience. 2 years korg and now this. Trust me it's not possible to cope with that for a long time :) Marek

20 years, 6 months

[linux-audio-dev] Re: [linux-audio-user] Linux audio hardware market research [was: creating a wiki "soundcard experiences" site]

by Marek Peteraj

On Sat, 2004-11-27 at 11:06, MarC wrote: > what about creating a wiki website to submit "soundcard experiences"? This also seems like a good idea to me, and it would be cool to have a knowledgebase like that. However i think that doing a survey in order to measure how big the linux audio market is is a different project. Similar to what David did, i imagine that a RME (or M-Audio) customer would submit his name, optionally email, choose type of his card from a list, and enter approx. date of purchase so that we can track the growth of the market(thus it's possible to roughly estimate its future growth). Also we'd need to announce it to a broad range of people, LAD/LAU/LAA, ALSA-dev/user/site, and Slashdot i suppose, so that we reach as many such customers as possible. Let's also not forget about OSS users which are also linux users. (I personally reckon a few people from #lad having troubles with alsa, they switched to oss for that reason). However, since i've got no php experience and very little mysql experience, i can't tell how hard it would be to do such a sumbit/log system. Marek

20 years, 6 months

[linux-audio-dev] gibson magic?

by smoerk

btw, is there anyone working on an implementation of gibson's magic for linux? is it even possible?

20 years, 6 months

Jump to page:

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