I wrote earlier:
> Ok. This didn't help, so I am going to scour my kernel configuration and
see if there is anything amiss.
>
> Luke
Ok haven't found the source of the problem, but I am able to successfully
mount CDs in my burner, but not in my DVD-ROM drive.
Still open to suggestions.
Luke
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
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
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
----------------------------------------------------------------------
> 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
>
>
>
> 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
> >
>
>
>
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
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>