On Sun, 28 Nov 2004 13:55:55 -0600, Ryan Gallagher <ruinaudio@xxxxxxxxxxx> wrote: > > Ryan, > > Good points to keep in mind. However, I can say that I use > > DigiDesign/Pro Tools 1394 under Windows with latencies that you would > > term acceptable so I know it *can* be done. Whether is can be done > > under Linux is another question. > > True, USB audio works wonderfully under windows and OS X. Sub 6ms > glitch free latency. But... Mark googling around I found discussions > you and I have had about USB/Firewire audio more than a year ago, then > resumed next year and now again for the third year: > > http://ccrma-mail.stanford.edu/pipermail/planetccrma/2002-December/000836.html > > http://www.eca.cx/lau/2003/12/0442.html It is true tha the two technologies approach the same problems quite differently.. > > Here's why I'm sadly of the opinion something like a custom 1394 card > wont work; > > More than two years pass and USB is still useless for low latency work > under linux. Anyone out there have a different experience? Probably not, but if so I hope they speak up... > > USB audio is ubiquitous in the windows/mac world and is pretty damn > common umong linux users I'm guessing. (How many laptop users out > there?) USB audio is a perfectly reasonable technology despite whatever > predjudices people may have. > > I'm left to believe that there is 1) not enough developer/user interest > to make USB audio work well or 2) linux is not up to the task of running > USB audio interfaces 3) (less likely) a strong bias against USB by > developers. > > Now if 1 or 2 are true for USB, I'm guessing they'll be true for > FireWire, if 3 is the reason for USB audio err... "not working so good" > on linux well... there may be hope for FireWire. Well, I think there is another HUGE problem that's hardly addressed in the Linux world. We all know it'd true. Many Linux developers do not have access to the hardware they are developing drivers for. I don't know if this applies to your hardware, but in my case Thomas Charbonnel never had the HDSP 9652 to do his development work with. It's no wonder that my driver problems were never explicitly solved. I think that in the case of an Open Source hardware project there is a good chance to put 5-10 of these in the hands of developers and to break that cycle. > > Either way, I'm sorry but if we can't even have functional low-latency > USB audio, how could it possibly be that FireWire will be supported, now > add to it the task of developing the hardware? Yep, it's a big problem. Huge. I appreciate folks like you and Ron Parker who will speak up and say what you think. It's important. > > Even were it to be supported, the USB user base must be absolutely HUGE > compared to any potential FireWire base. Current base - yes. Potential base - I think they are essentially identical. There's littel cost difference between the hardware cast of 1394 and USB. Most laptops come with 1394 today. USB has it's downsides also, which we are not discussing here, but they exist. > > > *Most* 1394 devices under Windows use the normal Windows 1394 > > driver. QUESTION: Are the Linux 1394 drivers up to the task? I'm not > > sure. > > I'm sure the generic 1394 drivers are approaching the performance of > windows now. But I'm operating under the assumption the audio end of > things are going to require a bit more coding. No - even 1394 hard drive performance is notably lacking compared to Windows. I've been on the 1394 development lists since 1999 when the project started. That team still says, after 5 years, that there is no work going on to improve performace measured by hdparm, etc. They are focused on just making it work reliably. When 2.6 came along the new team decided to rework almost the whole stack. They are still trying to make it work correctly. Folks on the 1394-users list still routinely tell people to stick with 2.4 kernels. We're now at Linux-2.6.9. Linux said he didn't expect 2.6 to take as long to get stable as 2.4 did, but stability is not only the kernel but all the pieces that attacha nd make the hardware work. Linux-1394 is probably 8-10 kernel releases away from stablity and real device support, unfortunately. (The are jsut my opinions and do not reporesent what that team might say of feel.) > > > > > I own 6 1394 peripherals. (3 hard drives, an external CDROM, an > > external DVD and a video conferencing camera.) All work perfectly > > under Windows. Under Linux 3 work, 3 do not. There are only about 5 > > people developing the 1394 stack under Linux. The stack has been in > > development since 1999. This does not make me confident about Linux > > and 1394 unless this hardware project was to undertake ensuring that > > the 1394 stack gets attention from our hardware/software developers > > should it need it. > > I can't see how it could possibly gain that needed attention. Well, that would be a problem, and if you are right then I would not undertake the program at all. > > > I will also raise the question 'why can't USB attain the latencies > > you want under Linux?' I *think* they can be attained under Windows, > > so why not Linux? Does this say something about the USB stack? USB > > support under Alsa? I don't know and I'm not capable of finding out. > > Ah, Mark but we've tried for years haven't we ;-) :-) ;-) :-) ;-) Yes, for many years... > > > > > Unfortunately, Alsa (as I see it, and which is probably an > > uninformed view) is really only a few people. I think that there are > > not enough people developing Alsa, and then developing Alsa drivers, > > to ensure it works as well as the hardware specs can support. > > > > As background, I helped write the 1394-2000. (Small contributions > > only, but I was part of the committee.) I can say with certainty that > > hardware like we are talking about was contemplated in the committee > > meetings. I firmly believe that this project is completely within the > > capabilities of 1394. Whether we are good enough hardware and software > > designers would have to be shown. On this point I am confident. > > Mark it's a knoble cause and I support your efforts, but... well I just > can't believe we could develop a FireWire Audio interface and > software/drivers to run it when exponentially more popular USB audio is > still languishing if not completely ignored. > > It's a horse before the carriage issue, the support will need to be > there before $$$ is invested in hardware, it's like designing and > building a car from scratch with no road to drive it on. > <hehe!!> I like that analogy. I don't totally share the gloomy picture, but I completely admit you might be right! - Mark
