Linux-audio-user June 2003

linux-audio-user@lists.linuxaudio.org

120 participants
118 discussions

Re: [linux-audio-user] Re: Processor Recommendation

by cliffw＠easystreet.com

> On Tue, 2003-06-10 at 13:19, Robert Jonsson wrote: > > tisdagen den 10 juni 2003 22.16 skrev Andrew Burgess: > > > >Hyperthreading - the new fancy P4's have it. Does it do anything on > > > >linux? I saw some benchmarks where it really sped up video encoding (on > > > >windows), how similar to sound processing is this? > > > > > > Alan Cox says HT provides 0-30% speedup. > > > > There was a recent thread on the Jack mailinglist where it seemed likely that > > latency would suffer when HT was enabled, if I read the thread right... It > > may had to do with using HT _and_ dual processors though, can't remember... > > The one I tested was a single processor P4 with HT enabled. With it > enabled I see latency spikes (10-15mseg) and weird behavior of Jack as > well. Steve (Harris) wrote something about threads not being happy on an > HT processor. So I guess we'll have to wait till there is better kernel > support (or maybe there is a kernel patch that fixes this?) The votes are still somewhat out on Hyper-Threading. The basic idea is the single processor has two state machines, and can thus inter-leave two streams of execution thru all the various queues and pipelines inside the CPU. The problem with Linux and SMP systems is with scheduling, since the current scheduler sees four processors instead of two, and it doesn't know which two are the 'evil twins' - bad for CPU cache warmth. Mostly fixed in 2.5, i believe. Dunno if there are backports to 2.4 available.. Basically, how 'good' HT performs depends on how 'tight' the code is. Code that grabs the CPU and runs intensively won't see any improvement from HT. The big improvements are seen when you have multiple processes that jump on and off the CPU, essentially the CPU doesn't have to flush the pipelines out so often. What you saw sounds like the bad scheduler stuff, forces extra TLB misses and causes hiccups. cliffw > > -- Fernando > > >

20 years, 3 months

Re: [linux-audio-user] newbie question about a Delta 1010LT card

by cliffw＠easystreet.com

> Sounds like you want to do multitrack recording. The card you have will > do that. If you're interested in a pro type of application you'll > probably want to run Ardour. Alternately there is ecasound and > Audacity. Check out my page > (http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html). > Very nice page - could you please add your .asoundrc to it? cliffw > Jan > > On Sun, 2003-06-08 at 10:59, Akos Maroy wrote: > > Hi, > > > > I just installed a Delta 1010LT multi-channel audio card into my PC. I'm > > new to multi channel cards, and have some questions. I'm sorry if these > > questions are dull or simple. > > > > I just installed alsa 0.9.4, as described on the page > > http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=Midiman&… > > > > all modules seem to load fine. > > > > I have the following questions: > > > > - mixer > > > > I can also run alsamixer and env24control, but I can't run aumix or > > other mixers that would use the OSS mixer interface. maybe the alsa -> > > OSS mixer interface is not configured properly, as: > > > > # cat /proc/asound/card0/oss_mixer > > VOLUME "" 0 > > BASS "" 0 > > TREBLE "" 0 > > SYNTH "" 0 > > PCM "" 0 > > SPEAKER "" 0 > > LINE "" 0 > > MIC "" 0 > > CD "" 0 > > IMIX "" 0 > > ALTPCM "" 0 > > RECLEV "" 0 > > IGAIN "" 0 > > OGAIN "" 0 > > LINE1 "" 0 > > LINE2 "" 0 > > LINE3 "" 0 > > DIGITAL1 "" 0 > > DIGITAL2 "" 0 > > DIGITAL3 "" 0 > > PHONEIN "" 0 > > PHONEOUT "" 0 > > VIDEO "" 0 > > RADIO "" 0 > > MONITOR "" 0 > > > > > > - accessing the multiple input channels as separate OSS devices > > > > actually the main goal of having this card is to be able to record > > parallelly from the separate input channels it has. recording would be > > done through opening and reading OSS-style /dev/dsp devices. > > > > is this possible using this card and alsa drivers? if so, how? is this > > related to /etc/asound.conf ? > > > > > > all help would be appreciated, > > > > > > Akos > > > > >

20 years, 3 months

[linux-audio-user] for those around los angeles

by Brian Redfern

Hi all, I've procured a weekly slot to do a live linux music peformance every week, and I also have some other slots availble for people so if you're in l.a. or coming here, check my website for more info: http://asapien.org

20 years, 3 months

[linux-audio-user] Re: [Ardour-users] Re: [ardour-dev] Re: [MusE] Re: Syncing muse with ardour

by Allan Klinbail

Hi I was going to do more testing of this earlier with a more reliable device than the MTPAV (the device is reliable, Id on't think the driver is just yet) but more stuff popped up I should get time this week.. although one question is the intel8x0 driver reliable for MIDI or should I install an old SB PCI128 (ens1371)? On Fri, 2003-06-20 at 11:22, Paul Davis wrote: </snip> > > >3. the *same* virtual midi interface is configured as MIDI port in muse, > >and is configured under MIDI Sync as Master-MMC O-Port. > > > >Though, transport is not reliably connected. Sometimes ardour seems to > >ignore the MMC sent by muse. > > any particular patterns associated with this behaviour? I found this true with external devices... I can't give a specific pattern b/c I was repeating the same action.. Play Start on MPC2000xl (start from beginning or start) Start on MPC2000xl (restart from wherever it is meant to be) Stop. It was the stop message that was missed most often.. > > did you try the other way around? i can't recall how much MMC ardour > generates. i know it will do some (if "Send MMC" is enabled). I did with beta1 and was not successful > > >>>>the third ardour MIDI option, which is called 'MMC Control' in ardour's > >>>>options panel, crashes ardour instantly! That may be part of the > >>>>problem, I guess... > > i'd like to track this one in more detail. i use this a lot and its > never caused a crash. I experienced this as well, but only until I hooked up an external device with MMC, it appeared as if once an MMC enabled device was hooked up I didn't have a problem. ... it doesn't seem logical though </snip> > > >>>> > >>>>How did you get syncing done, maybe even with ardour? Do I expect too much? > > MMC is not the correct method of syncing these two apps. JACK is. We > are still working on finishing the JACK transport API. Just FYI :) > > --p > Yes this makes perfect sense when audio is involved in MusE. However for those of us using MusE (or any other sequencer) to sequence outboard gear that is to be recorded as audio in ardour MMC makes sense and would be nice to use in the interim. Has the design of JACK transport taken into consideration MMC messages from outboard gear? cheers > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Ardour-users mailing list > Ardour-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ardour-users -- Allan Klinbail <allank(a)labyrinth.net.au>

20 years, 3 months

Re: [linux-audio-user] New powermacs?

by sh＠nnon.tv

fyi: This is the Apple "accidental" website posting in question: http://www.thinksecret.com/archives/g5fullpage.html

20 years, 3 months

[linux-audio-user] Re: Syncing muse with ardour

by Dave Phillips

Son of Zev wrote: > (firstly like to apologise to all on multi lists for cross posting but I > don't think this is necessarily just a MusE problem, it could be either > MusE, ardour or alsa and needs to be investigated further from all angles) (I've taken the liberty of transferring the topic to the Linux Audio Users list.) I have also been testing sync scenarios with Ardour (CVS 14 June) + various apps. I've had success only with Hydrogen. I worked with MusE (0.6.0pre5) for a while last night, nothing budged. I *thought* I had all connections designated: Ardour was set up for Send MTC and Send MMC, and MusE was set for external sync, recognizing MTC and MIDI clock. The Ardour sync output is the first virmidi port, so I used kaconnect to route virmidi 0 to MusE. The MusE console reports MMC stop and seek position signals for the Ardour playhead, but no start signal (should it?). Like I said, I got no sync joy. Audio is off in MusE, btw. Maybe I'm missing something obvious ?? Comix mentioned that seq24 would also sync to Ardour, but I couldn't make that happen either. I'm interested in learning about any successful sync arrangements, with or without external gear. What apps work well (or even sort of well) together via MMC, MTC, SMPTE, MIDI clock, or... ?? > I've just done some testing of various scenarios regarding syncing MusE > and Ardour and external devices.. via a MOTU Midi Timepiece AV (as the > code for this is not 100% solid I will redo this test with the intel8x0 > MIDI driver tomorrow at around this time.. it's too late now and I'm > back at work, I can't have the late nights I've been having lately) I have an old MQX32M stuck in a machine running MS-DOS and Sequencer Plus. That board + software generates and reads SMPTE and MTC (I think), I'll try testing it just for fun... Best regards, == dp > Versions > > MusE 0.60 > Ardour beta1a tarball > > (also no xruns were observed in this testing period) > > After some testing I suspect this may either be related to the way these > two softwares handle the virmidi device.. or how alsa handles midi > devices in general, or possibly the way MusE sends MIDI sync message. I > alos gather both from discussion and testing that the MIDI > implementation for sync in Ardour is not complete. > > NOTE: MTC/SMPTE can't be tested reliably on my system as mtpav won't > lock sync with alsa.. but MMC and MIDI clock work well > > Scenario 1 (mtpav/muse) > Syncing MusE to external MIDI device... very succesful, MusE is > responding well to MMC and MIDI clock signal.. moves with transport of > external device, keeps bar sync accurate. > > Scenario 2 (muse/mtpav) > Syncing external device to MusE .. reasonable success.. External device > recognises MIDI start stop, restart.. but external device doesn't sync > with transport movements on MusE > > Scenario 3 (mtpav/ardour) > Syncing Ardour to external MIDI device... moderate success a little > bit flaky at times,. missing a stop signals quite often but generally > working OK. Ardour sees MIDI transport messages including moving bars > forward and back.. > > It seems that the ability to see a stop signal and the ability to follow > the external transport are related (this is hard to describe) If I start > ardour and it can see a stop signal it does so consistently until it is > shut down, in this case it also recognises transport.. > > If it doesn't recognise the stop signal it won't do so until another > restart.. (no change in conditions). There is no way of setting up the > conditions to guarantee that ardour sees or doesn't see the stop and > transport moves.. (also transport moves are not in sync as ardour > doesn't recognise MIDI clock, although this is expecte behaviour as this > has not been implemetned as yet) > > Scenario 4 (ardour/mtpav) > Syncing External device to Ardour.. failed entirely.. a midi message was > seen to be passed through the mtpav but the external sequencer did not > register or understand this message as it had done with MusE. > > Scenario 5 (ardour(virmidi)/muse) > > 1. (external sequencer still was sending MIDI clock on first round of > tests) ....MusE responded unconventionally to messages sent by ardour... > (ardour set as master sending MTC and MMC) MusE would start when the > "go to start" button was pressed.. and stop on stop but only after play > had been pressed on ardour .. it would not start on "play" > > (2nd round external sequencer off) .. Nothing was received by MusE.. > > Scenario 6 (muse(virmidi)/ardour) > Syncing ardour to MusE.. failed.. > Even with all tracks set to broadcast via virmidi.. ardour did not > respond.. > > Scenario 7 > external (mtpav)-> MusE ->(virmidi) ardour.. > MusE would sync to external but ardour would not respond to MusE even > when no mtpav device was specified in a track (but enabled as a port) .. > MusE would still respond to the external device.. > > Scenario 8 > external (mtpav) ->ardour -> MusE > > Scenario 9 > - ardour > external (mtpav) - > - MusE > > setting up both apps to listen to mtpav port 1 (/dev/snd/midiC2D0) > > Success MusE only.. MusE again was responding to the external device > .. ardour did not respond.. > > A question for MusE/Werner... does MusE send received sync signals > through... (the sync options menu seems to indicate this and this is > desirable.. if it can be mapped to specific devices i.e. pass sync in > from mtpav to sync out virmidi, although this option is definitely not > presently apparent) > > So my results. show (with mtpav driver will test with intel8x0 2moro > combination on weekend) that MusE sends and receives sync from external > devices reliably.. Ardour receives MMC sync from external devices with > glitches.. but doesn't send reliably.. > > Neither sends nor receives sync via virmidi driver.. > > Hence the (or maybe my) ideal situation MusE synching with external > sequencer/transport and sending sync to ardour does not > > external --> MusE --> Ardour Failed.. > > I hope this helps.. > > Will send more results soon.. especially as I don't trust the mtpav > driver 100%.. (might install old ens1371 for reliable driver testing) > > cheers > > Allan > > > > On Wed, 2003-06-18 at 09:39, Martin Buechler wrote: > > Hi at muse, > > > > ardour-1.0 will not include a sequencer (AFAIK), and muse seems to be > > (I know, even more than) the complementary part to handle midi related > > recordings/overdubs. I thought, that all I would need is midi machine > > control with ardour as the master, muse as the slave. > > > > What I tried was: Directing ardour's - current is 1.0beta1-c - mmc to > > a virtual midi interface provided by the ALSA snd-virmidi module and > > driving muse as slave accepting mtc/midi clock/mmc with Id 127 and all > > ports.(Hmm, Whats the use of this Id anyway?) Selecting ardour's MTC > > generation seems not to change the behaviour of muse/ardour. Selecting > > the third ardour MIDI option, which is called 'MMC Control' in ardour's > > options panel, crashes ardour instantly! That may be part of the > > problem, I guess... > > > > Additionally, sync generation was turned off in muse. The transport > > grays out, and when I start ardour rolling, muse does exactly nothing. > > But, when I switch off/on the sync button in the transport panel of > > muse, then I am able to control stop/begin/end whithin ardour! Great, > > but it 's quite useless, when muse does not *start* with ardout, isn't it? > > > > Here's some output of muse -mMDs: > > > > ardour: > > ->Goto end > > (another thing: the bar counts seems to be actually not the same in muse > > and ardour) > > -- > > MidiInput: port:1 chan:193 port:1 chan:192 type:0xf0 a=8 b=0 data len 11 > > mmcInput: n:11 06 44 06 01 > > MMC: 156.560000 120238 seek 00:02:36:14:00 > > MidiInput: port:1 chan:193 port:1 chan:192 type:0xf0 a=8 b=0 data len 4 > > mmcInput: n:4 06 01 06 01 > > MMC: STOP > > -- > > ->Goto begin: > > -- > > MidiInput: port:1 chan:122 port:1 chan:121 type:0xf0 a=8 b=0 data len 11 > > mmcInput: n:11 06 44 06 01 > > MMC: 0.000000 0 seek 00:00:00:00:00 > > MidiInput: port:1 chan:122 port:1 chan:121 type:0xf0 a=8 b=0 data len 4 > > mmcInput: n:4 06 01 06 01 > > MMC: STOP > > -- > > > > -> Here I started ardour, but nothing happens.. > > > > Stop: > > -- > > MidiInput: port:1 chan:180 port:1 chan:179 type:0xf0 a=8 b=0 data len 4 > > mmcInput: n:4 06 01 00 00 > > MMC: STOP > > -- > > > > How did you get syncing done, maybe even with ardour? Do I expect too much? > > > > Thanks for reading. > > > > Martin > > > -- > Allan Klinbail <allank(a)labyrinth.net.au> > -- > Son of Zev <sonofzev(a)labyrinth.net.au>

20 years, 3 months

[linux-audio-user] RE: [linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]

by Ivica Bukvic

> -----Original Message----- > From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev- > admin(a)music.columbia.edu] On Behalf Of Erik de Castro Lopo > Sent: Sunday, June 22, 2003 3:29 AM > To: linux-audio-dev(a)music.columbia.edu > Subject: Re: [linux-audio-dev] New form of GPL licence that protects Linux > from proprietary world [was: New powermacs?] > > On Sat, 21 Jun 2003 22:16:52 -0400 > "Ivica Bukvic" <ico(a)fuse.net> wrote: > > > > I really don't see this as a problem. > > > > Do you mind saying why? > > Well people using libsndfile means that there are less people rolling > their own buggy implementations. This eventually means that libsndfile > has to handle fewer broken files due to someone else's buggy > implementation. > > But th emain reason is that most audio software requires a GUI. Any > program > that is Linux based will have an X11 GUI (at least to start with). On OSX > that GUI will always be slower that the Linux version. On mailing lists > for this software people will be told again and again that the performance > on Linux is better and sooner or later will want to try the real thing. I'll try to respond to many e-mails in one giant swoop :-). So here we go: But this might very soon become a non-issue. This has been a fact so far because G3 and G4 processors blew chunks (contrary to what Apple has been feeding its loyal crowds). G4 1GHz is roughly comparable to a 4-year old PIII 1GHz. However, with the newer chip, if it lives up to its expectations, this will disappear (even if OS X is a resource hog, eventually Apple's CPU's will be able to take it and remain standing on its feet). ---- Many of you have pointed out that limiting GPL would hinder the freedom it stands for. I agree. I never meant to change THE GPL, but rather to create an offspring GPL-like license that had my suggested restrictions. Someone mentioned "if Linux is meant to die, let it die". I completely disagree with this philosophy, because if that happens, and let's say theoretically other Unices go out of business, and we end up being forced to use, for instance OS X, then we would enter the era of indirect monopoly and all that GPL philosophy would not mean squat when we'll still be forced to use proprietary OS/Hw. Dual licensing perhaps is the best option at this moment. I feel very strongly about this since it protects all of our efforts and time investments in Linux. I would also suggest to be careful of the "elitist" talk how Linux' freedom offers less commonly used apps and hence the art of a Linux user is somehow better than of the others. A race car driver is undisputably better driver than I am (at least when it comes to racing, that is), but in order to be better he does not necessarily need to be a better mechanic than I am, right? That being said, I do agree that the tools we use help shape our art and in that way do affect the appearance of our art. I would just warn that not everyone is prepared to roll-up their sleeves hacking stuff, just in order to do a simple cross-fade two soundfiles. After all, how many ways are there to do this operation, regardless whether an app is oss or not? I guess, what I am saying is that I would love to see the LAD community continue to grow because after all the efforts we've made, I believe that _we_ deserve it (not some other proprietary OS), yet that appears not to be the trend (at least not in the academic circles). Ico

20 years, 3 months

[linux-audio-user] Re: [linux-audio-dev] New powermacs?

by cliffw＠easystreet.com

> Hi all, > >[snip - mac news - ] > > Please don't get me wrong. I am still in favor of Linux, obviously due > to its open architecture. But at the same time I am becoming a bit weary > of having to "hack" my advanced audio settings rather than use > user-friendly tools. That, coupled with still anemic direct vendor hw > driver support has really made me pay closer attention on Macs (as scary > as that sounds). Yet, I feel such a sense of accomplishment when my > Linux purrs just right with my desktop being uniquely configured and > tailored to my needs. After all, I am a geek. :-) And the inner struggle > goes on... > > Anyone care to comment or (please) dissuade me from potentially making a > costly mistake? ;-) > Well, i'm messing with a used iBook G3/500 right at the moment. OS X does look nice, and the few OS X audio apps i demo'd are solid. And, dual-booting w/Debian unstable was dead easy to do, i have OSS audio working jest fine with the built-in set, and i'm hoping to do ALSA via USB audio soon, which will be kewl. I like the hardware platform. The display is noticeably better than most Intel laptops, certainly better than the used ones i was comparing to. The Firewire Just Worked, right from the Debian install kernel. I've been using it with a IDE -> firewire disk carrier. The unit is solid. The built-in audio is okay, my model has no real inputs (built-in mic) - you would definately be using USB or firewire for Real Work. Using Open Firmware at boot instead of BIOS is sweet. With Linux, performance is fine, even with the 500mhz chip. The OS X on the other hand, is noticeably slooower than Linux (2.4.21 + 2.5.72 kernels ), especially at reboot. And the Mac world is insanely closed, it actually surprized _me how little choice you have with OS X - near as i can figure, you buy most everything from Apple, pay a bunch more money than a comparable M$ product, or suffer. And since they are _not a huge monopoly, they seem to have little shame about being closed - i was very amused by the way they attempt to corral the first-time user into signing up for .Mac (Apple's version of MSN) during the OS X install, iTunes also. The main thing-that-makes-me-nutbar is the keyboard layout. That's fixable with X, and you can set up keymappings with sysctl for some Mac-specific things. Main installation pain is the Mac version of fdisk, which is....terse. So in conclusion, i'd say the iBook + external converter (USB/fire) would make a fine Linux audio laptop. Get a decent sized disk, and you can dual-boot with OS X, and that will motivate you to run Linux again. :) cliffw (PS - http://www.penguinppc.org - is a good start point for Mac links) > Ivica Ico Bukvic, composer & multimedia sculptor > http://meowing.ccm.uc.edu/~ico > >

20 years, 3 months

[linux-audio-user] Mastering; Rezound, fir filter, digital clipping

by R Parker

Hi, I'm doing a study on audio mastering. Hopefully this letter will generate some correspondance from which I'll learn enough to augment a GFDL licensed document that I've been working on. The test job is an album I recorded several years ago. The source I've decided to use is 16bit 44100 audio CD. I'm restricting the applications I use to jack clients. I guess the process of copying audio and data from CD doesn't introduce any opportunity to compromise the sonic quality of the source. Am I right or wrong? Having opened the songs in Rezound, I've discovered that some of the songs have an inordinate amount of clipping--represented by vertical red lines on the time line. For the purposes of testing this is excellent because they're an opportunity to solve a common problem. The clips cause a series of questions for which I absolutely do not have definitive answers. Is what I am seeing clipping or is there a more accurate term to describe what I'm seeing? Perhaps someone could provide a technical explanation of clipping or a link to a definition. What tools do you use for eliminating clipping that already exists in a source? I don't care at all about preventing the problem. For the moment I am using the Rezound Arbitrary Fir Filter to identify the hz where the clips occur and am performing a decibal cut on the problem range. The interface for this filter enabled me to do some detailed work. Reguardless of how detailed I get, there's an audible consequence to eliminating the clips. I configured a preset with the minimal settings required to eliminate the clips but the result is audibly unacceptable. Another preset eliminates about 80% of the clips and audibly is marginally acceptable if applied to the entire file. What's interesting about this specific set of clips is that they are mostly inaudible. The clipping occurs around 10kHz -> 15kHz and are almost all within the high hat. This causes me to wonder: *how Rezound is configured to conclude that there are clips *should measuring for these types of problems be user configurable or does a technical specification define when a clip occurs *can engineers safely ignore inaudible clips and tell their clients that there's room to fudge and not to worry Is a Fir filter a good tool for addressing the problem of digital clips or is there something better? Are there alternative Fir filter algorithms that produce better results than the one being used in Rezound? I haven't a clue what Rezound uses. Anyway, there's a few of my questions which I realize are probably enough to exhaust anyone's patience. Reguardless, I really would appreciate your thoughts. ron __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

20 years, 3 months

[linux-audio-user] horgand-1.01

by holborn

Hi! again ... Hi! New Release : horgand 1.01 News in v1.01 (21/06/2003) ------------- -Fixed Bass frequencys, now are tuned :-) -Master Transpose transposes the bass line too. -Master MasterTune tunes the bass line too. -Added more chords to recognition. -Fixed small bugs in split, chords ... REQUERIMENTS: * FAST COMPUTER * LINUX * LIBSNDFILE * ALSA * JACK * FLTK 1.1 Web Page : http://personal.telefonica.terra.es/web/soudfontcombi/ Josep

20 years, 3 months

← Newer
1
2
3
4
5
6
7
...
12
Older →

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user June 2003