Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

Re: [LAD] Re: [linux-audio-dev] Direct Stream Digital / Pulse Density Modulation musing/questions

by Maitland Vaughan-Turner

On 9/24/07, Paul Davis <paul(a)linuxaudiosystems.com> wrote: > On Mon, 2007-09-24 at 13:13 -0700, Maitland Vaughan-Turner wrote: > > oh yeah, why is that? acoustic waves are continuous, analog > > representations are continuous. The more samples we can get the more > > closely digital representation can mimic the analog which is far more > > like the pressure waves than a series of pulses could ever be. > > there are lots of reasons why its wrong. information theory is one angle > to take: how much information is being delivered per unit time. biology > is another angle to take: how the human ear actually decodes acoustic > pressure waves. non-linearities in pressure transducers (speakers etc) > are another angle. the moment you convert an acoustic pressure wave into > an electrical signal, its properties start to change. leaving it in > analog form doesn't change it a lot. converting it to digital of any > type changes the properties quite a bit, but this makes no difference if > a symmetrical operation is possible when converting back to an analog > electrical. > > but basically: "more pulses with less information per pulse" isn't > equivalent to "less pulses with more information per pulse" and it > certainly isn't equivalent to "continuously varying analog signal". I dig what your saying, but when was the last time you listened to just a single sample? Granted a 24 bit sample contains a lot more data than a 1 bit sample. This is totally obvious. But when you look at a whole chunk of samples, only the first several samples of the 1 bit stream are a question mark. After several samples it falls into line and the amplitude can be accurately represented. Now, I understand that 1-bit 2.8 Mhz can not achieve the dynamic range of 24 bit samples, but it can surely represent more detailed waveforms. Besides, there is only one variable to maximize (instead of two). What happens when we turn that mega into a giga? (I know, I know, an even bigger processing nightmare... hahaha) Oh, and btw, just because I like DSD doesn't mean I don't like PCM! I totally dig your work, and I use Ardour all the time. (well, ok, it's broken on my box right now, but when it's working I use it all the time! :) I mean, c'mon dude, you're like a celebrity! Thanks for even talking to me =) ~Maitland

18 years, 2 months

[linux-audio-dev] Direct Stream Digital / Pulse Density Modulation musing/questions

by Maitland Vaughan-Turner

> On Tue, 22 Apr 2003 19:54:09 -0500 > "Dustin Barlow" <duslow at hotmail.com> wrote: > > > I read an interesting article on Direct Stream Digital (DSD) / Pulse Density > > Modulation (PDM) entitled "A Better Mousetrap" by Brian Smithers in the May > > 2003 issue of Electronic Musician. Since, Brian did a good job explaining > > PDM/DSD in quasi-layman terms, I'll just quote snippets from his article to > > set the stage for my questions. > > <snip> > > > DSD/PDM appears to be a superiour technique for recording and playing audio > > material. > > Having been around digital audio and digital signal processing for over 10 > years, I am still far from convinced. > > > Granted, this technology may never catch on because of all the > > hardware and software changes that would be required to mirror what a > > typical PCM based DAW currently does. But, if DSD/PDM does catch on, and > > DAWs start being produced, how will this effect current audio DSP > > techniques? > > I have not looked into the maths behind algorithm development in DSD/PDM, > but I doubt it is anywhere near as easy as with PCM. > > > The article mentions a program called Pyramix (Windows) which features DSD > > support. However, for Pyramix to do EQ, dynamics, reverb processing, and to > > display waveforms and vu levels, it converts DSD to a "high quality" PCM > > format. > > That should tell you something :-). <snip> So..? Most PCM converters utilize a 1-bit stream also. Why not utilize all the tools available for the task at hand? As for processing, you can look at a PCM representation of a waveform to ease the processing load and then just apply the changes to the orignal DSD stream without ever having to process in the 1-bit domain directly (which is way more processor intensive since you have to look at a huge chunk of the stream in order to extract the amplitude data that is available in each multi-bit sample). IMHO, though, the hippest alternative at present is to process a DSD stream in the analog domain and re-record it to DSD. This results in a very "analog" sound. These days you can get analog gear with a respectable dynamic range for a song (Mackie Onyx anyone?). When you can get a 130 dB S/N ratio in the analog domain you really don't lose too much converting back and forth from 1-bit domain. It's freakin sweet! If you haven't tried recording 1-bit. Do yourself a favor and demo one of the new Korg recorders. It really is really good, no kidding. ~Maitland

18 years, 2 months

Re: [LAD] Re: [linux-audio-dev] Direct Stream Digital / Pulse Density Modulation musing/questions

by Maitland Vaughan-Turner

On 9/24/07, Paul Davis <paul(a)linuxaudiosystems.com> wrote: <snip> > > i'm afraid that you first have to convince a group of people with far > too much to do already that there is something worthwhile about this. > i've been following DSD for 4-5 years, and i not only unconvinced, i am > certain that its nothing but marketing BS. heh, that's ok if I don't convince anyone to do anything. If you just spend some time thinking about it, that's cool to me. Even if that thinking is just trying to explain to me why you think it sucks. ...mmmm electric kool-aid, lol ~Maitland

18 years, 2 months

Re: [linux-audio-dev] Direct Stream Digital / Pulse Density Modulation musing/questions

by Maitland Vaughan-Turner

> > ------------------------------ > > Message: 2 > Date: Mon, 24 Sep 2007 11:28:17 +1000 > From: Erik de Castro Lopo <mle+la(a)mega-nerd.com> > > > First off, why are you reprising a 4 year old thread if you don't have > anything new to add? Uhh, what about experience? I've actually used a 1-bit recorder. You can talk about theory and quote papers all day, but that doesn't mean *anything* compared to actually making recordings all day. Also, things have changed a lot in 4 years. Now 1-bit recording is available to everyone. Unfortunately, however, there are no linux alternatives for dealing with 1-bit files. I just thought a bit of discussion on this list might help with that. > > Maitland Vaughan-Turner wrote: > > > So..? Most PCM converters utilize a 1-bit stream also. Why not > > utilize all the tools available for the task at hand? > > Yes, but you need to analyze what you are doing or the next thing > you know you are paying mega dollars for triple gold plated single > direction, rare earth metal interconnect cables and other such > snake oil. > > > As for processing, you can look at a PCM representation of a waveform > > to ease the processing load and then just apply the changes to the > > orignal DSD stream without ever having to process in the 1-bit domain > > directly (which is way more processor intensive since you have to look > > at a huge chunk of the stream in order to extract the amplitude data > > that is available in each multi-bit sample). > > Problem : the conversion from DSD and PCM is lossy [0], hence doing > DSD -> PCM -> DSD -> PCM is a bad idea. that's true, it's not the route I would take, but doing some effects in PCM and mixing those with the original stream (either analog or pure DSD mixing) results in more clarity than working wholely in the PCM domain. > > > IMHO, though, the hippest alternative at present is to process a DSD > > stream in the analog domain and re-record it to DSD. > > Two problems: > > - A-to-D converters are limited to about 20 bits of SNR due > to things like silicon junction noise and those noisy > electron thingys. heh, i didn't say it wasn't lossy I just said it was hip. Like, it sounds cooler (to me) than using a DAW. > > - All commonly used audio A-to-D converters are 1-bit so every > time you go to analogue and then into a digital effects box > you are doing another DSD to PCM conversion. Is this a bad thing? I never said PCM sucks or anything. Haven't you ever used an effects send/return, anyway? You don't have to send the entire signal through the box. The affected signal is mixed with the original signal. I'm also using DSD to record a guitar running through a 20bit PCM hybrid effects and a 16 bit keyboard and occasionally a V-Drum set. Oh the blasphemy! :) > > See reference [0] below. > > > This results in a very "analog" sound. > > So, you have a way of objectively measuring how "analog" something > sounds? I'd be interested in hearing your methodology. not objectively. I just use my ears. I record my band and the detail and clarity of the recording in DSD format is striking (compared with PCM). This kind of detail I can only hear when playing vinyl records. That's why I say it sounds more "analog." Intuitively, one could also say that more sample points yield a waveform that is closer to a continuous, analog waveform. Thus it sounds more analog. > > > These days you can get analog gear with a > > respectable dynamic range for a song (Mackie Onyx anyone?). When you > > can get a 130 dB S/N ratio in the analog domain you really don't lose > > too much converting back and forth from 1-bit domain. > > Where is you analogue to digital converter which also has 130dB SNR? well, right, I'm saying the analog gear (that I have) is higher quality than the digital gear. Of course, there is going to be some change in sound everytime you switch domains, but is it a loss or is it a gain?? I think it mostly depends on the skills of the audio engineer. > > Erik > > [0] Why 1-Bit Sigma-Delta Conversion is Unsuitable for High-Quality > Applications, > Stanley P. Lipshitz and John Vanderkooy > http://sjeng.org/ftp/SACD.pdf Thanks for the link. My whole point of digging up this old thread though, was to say that I've tried it, and my ears tell me that the papers are incorrect. IMO, 1-bit recording is LSD not snake oil... ...have some of the kool-aid, it's the good stuff ;) ~Maitland

18 years, 2 months

ESI MIDImate driver

by Mark Watkins

I am trying to get the ESI MIDImate (EGO SYstems) to work. I am running 2.6.17-5mdv and here is the /proc/bus/usb/devices entry: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0a92 ProdID=1001 Rev= 1.04 S: Manufacturer=ESI S: Product=ESI MIDI Mate C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr= 20mA I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 4 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 4 Ivl=0ms The problem appears to be that the snd-usb-audio driver will not load. My /etc/hotplug/blacklist includes usb-midi to avoid driver conflicts. The dmesg output is usb 1-1: new low speed USB device using uhci_hcd and address 4 usb 1-1: configuration #1 chosen from 1 choice unknown device speed 1 snd-usb-audio: probe of 1-1:1.0 failed with error -5 unknown device speed 1 snd-usb-audio: probe of 1-1:1.1 failed with error -5 /proc/asound/version says ALSA v1.0.12 is installed. How do I get the driver to load? === Mark Watkins <email suppressed>

18 years, 2 months

[ANN] Snd-ls V0.9.8.2

by Kjetil S. Matheussen

Snd-ls v0.9.8.2 =============== Snd-ls is a distribution of Bill Schottstaedt's sound editor SND. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Snd-ls also serves as base code for the San-Dysth softsynth (http://www.notam02.no/~kjetism/sandysth/) and the Snd-rt music programming language (http://www.notam02.no/arkiv/doc/snd-rt) Changes 0.9.7.12 -> 0.9.8.2 --------------------------- -The rt_readin_tag startup bug is finally fixed. Thanks to Josh Lawrence, Luke Hammon, Martin Rumori and Renick Bell for helping me finding it. -Improved the build system a bit. -Guile >=1.8.0 is now required to build and run Snd-ls. -Fixed bug that caused snd to fail starting if no previously used soundfile was opened during startup. -Updated Snd from 8.4/12.9.2006 to 9.3/30.7.2007. Many important fixes. Download from http://www.notam02.no/arkiv/src/snd/

18 years, 3 months

[RESOLVED] Server crash

by Marc-Olivier Barre

Dear mailing list users, As some of you might have noticed, the lists on linuxaudio.org have gone silent for two whole days. This incident was due to a crash of the mailman process. The exact causes remain as of yet unknown, but will be investigated. Please accept our apologies for this disturbance. Kindest regards, __________________ Marc-Olivier Barre.

18 years, 3 months

Looking for a programmer

by Andres Cabrera

Hi all, Please let me know if this is inappropriate for this list, and I promise never to do it again... I'm looking to hire a programmer to help me finish a GPL'd audio application. Requirements: - Excellent knowledge of C++ - Experience with QT4 - Experience with audio applications (especially using jack and libsndfile) Desirable: - Experience with XML processing in C++ - Experience with QTDesigner - Experience with OSC in C++ The job involves two weeks full time work on a GPL'd application. Work can be done remotely via cvs commits to a sourceforge repository. If interested, please send CV to mantaraya36(a)gmail.com, stating desired fee. Thanks and sorry for the noise. I felt this was the place to post, as this list surely has the most talented people for the job... Cheers, Andrés

18 years, 3 months

Re: [LAU] FIC neo1973 linux mobile

by Marc-Olivier Barre

On 9/18/07, Robert Jonsson <rj(a)spamatica.se> wrote: > Hi folks, > > Lots of talk today about linux mobiles on the internets. Apparently > Trolltech has ported Qtopia to the neo1973 linux mobile. Interesting > news in itself. > Even more so the neo1973 seem to be a very interesting device in itself. > > I only very quickly glanced through the specs on the openmoko site, it > looks to be a very capable device with interesting possibilities. > > Apart from pretty much all mobile devices I know it seems to have USB > host-controller possibilities which should make it possible to connect > an USB soundcard to it. Would make a splendid recording/playback device. > > Also, on this page: > http://wiki.openmoko.org/wiki/Neo1973_Audio_Subsystem there are some > schematics of the audio hardware which also seem interesting. Possibly > there's both stereo line in and stereo line out, the inputs seems to > route through some "Voice codec" "thing" though... > > Anyone know anything more about this device? Hi Robert, I've been following this project for a while now (I'm waiting the release of the public version of the Neo in October to get one), most of the useful info is on the wiki. I won't recommend the chat room on freenode. It's far from being as interesting as #LAD ;-) Anyways... What I think is that is would make perfect studio remote controle (in addition to a phone) since it has a touch screen. Fact : Did you know that Apple had the idea of the iPhone a few weeks after Sean Moss-Pultz (the project leader at FIC) made a public presentation of the openmoko project ? Funny... BTW, I managed to build a jack package for an emulated Openmoko system in a matter of minutes. I'm sure I've lost the package since then, but just so you know jack runs out of the box on an arm (if compiled without any optimization of course). CCed to LAD since some people might find this interesting... Cheers ! __________________ Marc-Olivier Barre.

18 years, 3 months

Re: wine, vst, 64bit

by Dave Phillips

Marco Milanesi wrote: > By following LAD/LAU lists, I see that you are using pure 64bit >arch, could you confirm that VSTs with 32 bit wine works? > > Hi Marco, I've cc'd this response to the lists because I want to clarify the situation for all who are interested. The short answer is, "Yes". The longer answer is "Yes, with some very specific caveats." Wine can be compiled as a 32-bit binary for running in a pure 64-bit system. I'm running such an arrangement now, with backport packages of Wine and libwine 0.9.34 (Debian, 64 Studio). However, IIRC 64 Studio already has more recent packages available. The biggest problem is latency. In this scenario it's not possible to use the JACK/wineasio combination, so you'll end up using either the OSS or ALSA sound system for Wine (select in winecfg). It may be possible to lower latency with either of those drivers, but I've not worked at it. So far I've only tested Reaper with some VST plugs. It worked, but I wouldn't try using it as a production environment. I haven't yet tested any other hosts. And just to be clear: At this time I would advise anyone who wants to run VST plugins in production to do so with either JAD or 32-bit 64 Studio. They support the wineasio driver, thus greatly improving the latency numbers. Best, dp

18 years, 3 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