Linux-audio-user

linux-audio-user@lists.linuxaudio.org

20661 discussions

[linux-audio-user] Problems with kernel 2.4.21 and mounting CD-ROM devices.

by Luke Yelavich

Hi all. I am wondering whether anybody else has experienced lock-ups when trying to mount a CD-ROM device using kernel 2.4.21 with low latency and preempt? I have tried with SCSI emulation, as well as normal IDE. I am currently re-compiling without low latency and pre-empt, but wondering whether this is a reported kernel problem, or a problem that these patches may have introduced? Any ideas or suggestions are welcome. Regards Luke

22 years, 4 months

[linux-audio-user] (no subject)

by Luke Yelavich

I wrote earlier: > Hi all. > I am wondering whether anybody else has experienced lock-ups when trying to mount a CD-ROM device using kernel 2.4.21 with low > latency and preempt? > > I have tried with SCSI emulation, as well as normal IDE. I am currently re-compiling without low latency and pre-empt, but wondering > whether this is a reported kernel problem, or a problem that these patches may have introduced? > Any ideas or suggestions are welcome. > Regards > Luke Ok. This didn't help, so I am going to scour my kernel configuration and see if there is anything amiss. Luke

22 years, 4 months

[linux-audio-user] recording multiple input audio streams

by Hirendra Hindocha

Hi, I'm looking for solution where we can record multiple input streams of audio to individual files which can then be processed by other programs on Linux. I've searched the ecasound list and also the archive of this list. The best I could find was a similar requirement by someone using a Delta 1010 card. One of the solutions that was proferred was to use the JACK audio server. Is it possible to connect multiple input streams of audio (think multiple phones or line-in from multiple VCRs or any audio device) and individually record the streams as a digital file ? For example - 911 calls , or financial transaction calls etc I'm looking for a Linux based solution that can do that - Ideal would be - a. Well Supported card that has multiple line-in ( so if I want to record 8/16 audio inputs, it should have 8/16 line-in sockets) b. Software to record the line-in audio c. Software to encode it if b & c can be combined to record and encode like ecasound, it would be perfect. I asked around on the ecasound list and was directed to this list. We're not looking to do any mixing or sound editing. Our requirements are very simple. Ecasound works very well for us when using one sound card. We now need to scale this solution so that we can record the equivalent of 8/12/16 sound cards each having an instance of ecasound recording and encoding. A similar solution on the Windows platform seems to be http://www.dictaphone.com/products/freedom/freedomps/ Any help is highly appreciated, -- Hiren ----------------------------------------------------------------------

22 years, 4 months

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 > > >

22 years, 4 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 > > > > >

22 years, 4 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

22 years, 4 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>

22 years, 4 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

22 years, 4 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>

22 years, 4 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

22 years, 4 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-user