Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Re: This better not be patented...

by Juhana Sadeharju

>From: Jens M Andreasen <jens.andreasen(a)chello.se> > >> The article says quite clearly that the invention is patented. >> They would be fools not to try to patent it because the market >> is huge. > >I did not find any references to patents except for the word >"invention". Not even "patent pending"? It was this version of the news: http://www.tomshardware.com/hardnews/20040902_135943.html "Pricing was not announced yet, but Cann says he will make his technology available for "far less" than the cost of professional studio DSP solutions which can run into the high five-figure range. He estimates the price will be somewhere between $200-$800." The "technology" is the way how audio is stored to texture memory. And the audio is apparently stored as float data as the text below could indicate. "At this time, Cann plans to only support Nvidia graphics cards. "When I started, ATI had a problem with floating point data. I have heard they have resolved it, but I won't have time to purchase and research their newest cards until after this is released," he said." Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

21 years, 1 month

[linux-audio-dev] A statement regarding DSSI

by Mario Lang

Hi. Some of you might remember that I once started a thread regarding the not-so-good separation of the GUIs from the DSP engines of typical LAD applications. I just took the time and looked at DSSI, and as far as I can see, it would solve most of the problems I am having regarding UIs. The OSC based UI->to->host communication concept nicely separates the actual UI from the DSP code and forces the developer to separate the GUI code from the actual backend. This would make it as simple as possible to replace existing UIs with alternative approaches. The DSSI plugin could be reused as a whole, unmodified, only the UI part would need to be re-written. Thanks to those who work on DSSI, it looks very promising to me. Any early adopters yet? -- CYa, Mario

21 years, 1 month

[linux-audio-dev] a question re: the MIDI spec

by Dave Phillips

Greetings: I'm doing some research for an article about Linux MIDI support. In my text I briefly describe the evolution of the MIDI specification since its adoption, mentioning things like MIDI Time Code, MMC, the sample dump standard, and the standard MIDI file. However, one item has me a bit mystified. I'm unable to ascertain whether multi-port interfaces are in fact described and supported by the spec. I checked the MMA docs on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers Handbook, but nowhere do those sources indicate explicit support for multi-port hardware. Are multi-port MIDI interfaces vendor-specific solutions or is there actually an extension to the MIDI spec somewhere that I'm just missing ? TIA! Best regards, dp

21 years, 1 month

[linux-audio-dev] [ANN] Prerelease of libgdither 0.2 dithering library

by Steve Harris

Invitation for testing and API comments. http://plugin.org.uk/libgdither/ Libgdither is a GPL'd library library for performing audio dithering on PCM samples. The dithering process should be carried out before reducing the bit width of PCM audio data (eg. float to 16 bit int conversions) to preserve audio quality. It can do conversions between any combination of: in out (optionally interleaved) ------------------------------------------------------------- normalised mono float 8bit unsigned ints normalised mono double 16bit signed ints 32bit signed ints normalised float normalised double At any bitdepth supported by the input and output formats Instructions for testing are in http://plugin.org.uk/libgdither/TESTING Basic docs can be found in http://plugin.org.uk/libgdither/libgdither-0.2/gdither.h Examples of use can be found in http://plugin.org.uk/libgdither/libgdither-0.2/examples/ex1.c Comments welcome, Steve

21 years, 1 month

[linux-audio-dev] Re: Audio synchronization, MIDI API

by John Lazzaro

On Sep 13, 2004, at 9:01 AM, Eric Rz wrote: > So at what level in the tcp/ip stack does a collision get detected? > From > what I understand, if there is a collision on a network segment each > end > will backoff for a randomly chosen time and then retransmit. Is this at > the ethernet, IP, or TCP level? If you're designing the interface between Layer-2 (Ethernet, Wi-Fi, what have you ...) and IP, as a rule, the right thing to do is to pass through packet loss rates in the 1-2% range to the IP layer. If the Layer-2 sees loss rates significantly above that on a regular basis, IP applications are known to not cope well, and so the right thing to do is to make the Layer-2 appear to have a 1-2% packet loss rate, by using techniques like retransmission or FEC. Modern Ethernet (what you buy new from Linksys or Netgear or Cisco in 2004) is switched, not shared. It achieves 1-2% loss rates extremely easily. So, stacks usually pass through the tiny loss rates of switched Ethernet up to the IP layer. This means that yes, occasionally you will see lost packets if you a UDP application (UDP is a thin layer on top of IP, one IP packet to the OS == one UDP packet to an app) on a local switched Ethernet. I've seen it with real hardware. Usually, the network is having a burst of traffic, and something -- probably the receiving network stack -- gives up and throws away a packet. But, its very rare -- 0.1% or less, if I had to put a number on it. But if that 0.1% was a NoteOff sent to an Hammond organ patch, you care :-). Thus, the recovery journal technology in RTP MIDI. Shared media wired Ethernet technology got us through the 80's. Which was a good thing :-). But it really is a technology for the history books now ... its really good history, its good to know about it because it was such a classic design, but its not what people mean anymore when they say "wired Ethernet". All that is left from that era is the bit-field -- the pattern of bits in the packet -- and the semantics of the bits. Modern wired Ethernet is switched Ethernet. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

21 years, 1 month

[linux-audio-dev] Re: Audio synchronization, MIDI API

by Andrew Burgess

>In pratice people dont really demand hard realtime and it will be OK, but >the maximum time taken to transmit a UDP packet is unbounded, it uses >exponential backoff IIRC. That sounds like TCP. I think UDP is send and forget, if you want guaranteed delivery or sequencing you need a higher protocol like TCP. Or are you thinking of ethernet level collision detect and retransmit? Does that go on forever (unbounded)? (Sorry I know it's an older thread, I'm trying to catch up ;-)

21 years, 1 month

[linux-audio-dev] realtime-lsm in the kernel

by Lee Revell

Hey, Now that the final touches are being put on the 2.6 low latency patches, a massive migration of linux audio users to 2.6 is imminent. Since this means every single linux audio user will need the realtime-lsm module, I think we should push to get it in the kernel, the sooner the better. Why make every user go through the extra step of downloading and installing it? It's only a few hundred lines of code, and while I don't consider myself a kernel expert I can grok it easily. I can't imagine there would be much resistance, especially considering how much easier this would make life for every audio-oriented distro. This fits the new kernel development model very well, one of its stated goals is to get the features that vendors and users need and that they currently have to patch the kernel to get, into the mainstream kernel. Anyway if the author does not object, I would be willing to spearhead a drive to get this into the kernel. I am sure they will approve as soon as 100s linux audio users voice their approval... Lee

21 years, 1 month

Re: [linux-audio-dev] a question re: the MIDI spec

by Pedro Lopez-Cabanillas

On Friday 10 September 2004 Martijn Sipkema wrote: > The problem here is that class compliant devices suffer bad timing > because they use bulk transfers for MIDI data. The standard for > MIDI over FireWire is much better. I don't agree on the subject that USB bulk transfers cause bad MIDI timing. Of course, you can't use the same USB host controller at a time with a MIDI interface and some other device like a CD writer and expect both good MIDI timing and fast CD burning. If you can reserve a host controller exclusively for your USB MIDI device, you will get pretty good results, most of the time. There are four USB data flow types, Control transfers and: - Bulk transfers are used to request or send reliable data packets up to the full bus bandwidth. Devices like scanners or scsi adapters use this transfer type. - Interrupt transfers are similar to bulk transfers which are polled periodically. If an interrupt transfer was submitted the host controller driver will automatically repeat this request in a specified interval (1ms - 255ms). - Isochronous transfers send or receive data streams in realtime with guaranteed bus bandwidth but without any reliability. In general these transfer types are used for audio and video devices. (quoted from http://wwwbode.cs.tum.edu/Par/arch/usb/usbdoc/node8.html) MIDI streams need to be reliable (a single byte lost isn't acceptable), so Isochronous is not an option. Interrupt or Bulk transfers are very similar: they use only the available bandwidth at each moment, so there can be unwanted delays and timing problems. Some manufacturers' proprietary protocols include a timestamp with each USB MIDI packet to enhance the time accuracy, but this can be done either in bulk or interrupt transfers. Regards, Pedro

21 years, 1 month

[linux-audio-dev] [ANN] tuneit 0.2 -- ALSA and JACK instrument tuner

by Mario Lang

Hi. Here is it, the first public release of tuneit, a command line instrument tuner for ALSA and JACK. tuneit was written as a command line alternative to the two existing guitar tuner programs for GUIs (gtkguitune and qjacktuner). It offers two different fundamental frequency detection algorithms. The default (Schmitt Trigger) algorithm is very light on CPU usage. Alternatively there is also a FFT based algorithm which is much more CPU intensive but a little more acurate and/or stable. Thanks go out to Karsten Wiese and Florian Berger, the authors of qjacktuner and gtkguitune respectively, whoes work has served as inspiration for tuneit. "Screen shots": Tuning my guitar via ALSA hw:0 with the simple Schmitt Trigger algo: lexx:/# tuneit Note A ( 110.000Hz): -8 cents ( 109.506Hz) Or via JACK: lexx:/# tuneit -j Note A ( 110.000Hz): -5 cents ( 109.714Hz) Or with the FFT algo via JACK: lexx:/# tuneit -j -f Note A ( 110.000Hz): -7 cents ( 109.565Hz) Show the available JACK ports: lexx:/# tuneit -j -i alsa_pcm:capture_1 alsa_pcm:capture_2 Capture from right channel via JACK using a FFT window size of samplerate/5: lexx:/# tuneit -f -l 5 -j alsa_pcm:capture_2 Note A ( 110.000Hz): -5 cents ( 109.656Hz) Download: The canonical homepage for tuneit is http://delysid.org/tuneit.html Version 0.2 can be downloaded from http://delysid.org/tuneit-0.2.tar.gz Comments, as always, are very welcome. -- CYa, Mario

21 years, 1 month

Re: [linux-audio-dev] a question re: the MIDI spec

by Pedro Lopez-Cabanillas

On Friday 10 September 2004 Eric Dantan Rzewnicki wrote: > On Thu, Sep 09, 2004 at 07:18:57PM +0200, Pedro Lopez-Cabanillas wrote: > > And now Avid (the company owning Digidesign) bought M-Audio. [...] > Really!?! when did that happen? http://www.avid.com/company/releases/2004/040820_acquisition.html http://www.m-audio.com/index.php?do=media.new&ID=503e85ec37f1003524a4455fcf… http://www.m-audio.com/images/en/press_releases/Avid-M-Audio_PR.doc Regards, Pedro

21 years, 1 month

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