Hi,
has anyone tried the M-Audio Transit USB with ALSA yet? (Its bigger
cousin, the USB Audiophile is supported according to alsa-project.org.)
I'm looking for a not-too-expensive USB audio interface for my laptop,
and the Transit would fit nicely, as I already have a usb midi interface.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
> Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote
> On Thu, Jan 27, 2005 at 11:06:29 -0500, Paul Davis wrote:
>> http://namm.harmony-central.com/WNAMM05/Content/Waves/PR/Q-Clone.html
>
> Hmmm... I suspect thats rather easy to do, infact JAMin has most of the
> code to do that, but its a really clever idea. OTOH, I dont actually
> have
> any outboard EQ thats worth cloning, but hey, still a nice idea.
I wonder if linear models of the classic tube EQs are really
sufficient to recreate their special character ... or if they needed
to go to non-linear models. A non-linear approach would add
a whole level of complexity to the system, the outboard would
need to be probed at many amplitude levels, and the amplitude
level of the input of each cloned EQ would need to be monitored, etc.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
I was interested in the thread about firewire audio device support
in Linux a while back. Just the other day I noticed that Presonus is
just up the road from where I live so I thought I'd drop them a line and
ask about their two firewire interfaces and if they would consider
releasing specs to the Linux audio community to get drivers written for
them. I received two responses, both of which seem promising:
> Hi Jan,
> We have a Linux fan within our engineering group. I feel certain that
> we
> could provide driver information for the development of Linux based
> FireWire connectivity.
> .
> .
> .
> Please let us know who to contact.
> Kind regards,
>
> Jim Odom
> President/CEO
> PreSonus Corporation
> 225-216-7887 ext. 107
and:
> Mr. Depner
> I'm the engineer interested in Linux that Jim Odom spoke of. I in no
> way
> claim to be even an experienced Linux user, I like the idea behind
> it. I
> can tell you that there is ongoing development of a Linux driver for
> products based on the firewire solution that we employ. The name of
> the
> company whose solution we use is BridgeCo...you might be able to
> google some
> info...no promises. I'm not sure what they've released to the open
> source
> community at this point...but I can tell you they are working on it.
> Thanks
> for your interest in PreSonus and BridgeCo, and if you find out
> something...let me know!
Just thought I'd throw this out on the list to see what feedback I
get. I hope I didn't step on anyone's toes. If you know someone who
would be interested in working on drivers please pass this to them.
Contact information for Presonus is available on their web page.
Jan
I am writing a HOWTO for the benefit of knoppix users
who want to utilize rosegarden21 which is included on
the knoppix LiveCD.
Since this is for the LiveCD users, upgrading to
rosegarden4 is not an option.
I figured out how to get /dev/sequencer working, now
sndstat tells me my first device is "MPU-401 0.0 Midi
interface #1" and I am able to get rosegarden to
output midi.
However, I'm unable to get rosegarden21 to record any
midi notes. On my midi setup screen, it lists the
device as /dev/sequencer, and the record device (which
I cant modify) says (null device), then if I try to
record and check again, the record device says
"MPU-401 0.0 Midi interface #1" but no note events
got recorded into the track.
I know most everybody's moved away from OSS to ALSA
but does anybody remember how to test the midi input
under OSS? I can't tell if my /dev/midi is working
like my /dev/sequencer is.
BTW I notice the notes I play on my midi keyboard do
trigger the module connected to the soundcard's midi
out even with no application running.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi All -
The attached patch improves on the patch posted
Friday night on the same subject.
1. a line from my copy of sound/usb/usbaudio.c didn't
make the earlier patch and it's essential
2. the earlier patch was treating the output stream as
USB Bulk when it should be USB Interrupt (1ms)
3. the earlier patch was not dealing with input properly
causing the input side to become inoperative after
the first application closes the MIDI device.
As before, this has been built and tested (and tested...)
on the latest Fedora Core 3 kernel from updates-released
(the 741 kernel) using an X-Station with the latest X-Station
firmware on a uniprocessor 32-bit intel machine.
The patch should apply cleanly to any kernel tree with
ALSA 1.7 and build just fine.
As before I'd be glad to hear feedback from people trying
this patch out with Novation Speedio or Novation ReMOTE 25
(the MIDI-only one).
Thanks in Advance,
ccb
Next: Mixman DM-2
Hello.
The old OASYS had a hardware card with five DSPs.
Korg provided the patch editor for those who asked it
separately. The same editor was used to make the
preset patches by Korg people, if I remember correctly.
It looks like I don't have the module documentation,
I have only Patches and Effects doc. Perhaps it came with
the patch editor. Anyone?
Hey. Nobody wrote details here. Was the given url empty or what?
Is it standalone keyboard with Linux inside? Is it an audio card
like the old AOSYS but they now provide the patch editor running
in Linux? Does it have the patch editor included?
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
http://namm.harmony-central.com/WNAMM05/Content/Lexicon/PR/MX200.html
Seems relevant to the linux reverb plugin questions. I would imagine that
the plugin sends out a packet of samples over USB, and receives a packet
back, maybe with a one packet slip to reduce the plugin processing
latency, at the cost of overall latency.
I wonder if they'd be willing to release the USB protocol they use. Its
possible they compute some of the reverb inside the plugins (eg. the ERs)
as a cheap hack to hide USB latency. More likly they dont bother though.
If the protocol is simple enough it could be sniffed from a windows box.
No info on pricing yet.
- Steve
I posted this to alsa-devel but since my previous post on this list
generated a lot of interest, I am just reposting it here.
As promised, here's an updated patch to add real multichannel playback
support (and improved multichannel capture) to the emu10k1 driver.
http://www.alsa-project.org/~rlrevell/emu10k1-multichannel-v001.patch
Please test it and report any problems. I am especially interested in
any regressions that impact regular PCM playback (the hw:0,0 device).
QuickStart:
$ jackd -R -v -d alsa -P hw:0,3 -C hw:0,2 -S
I tested this and it works well with 16in/16out at 128, 256, 512 frames.
32 and 64 should work too but I can't test as I'm running a stock 2.6.10
kernel for now ;-). You can check that the routing is correct by
connecting a JACK client to the playback ports corresponding to the FX
buses described in Documentation/Audigy-mixer.txt and
Documentation/SB-Live-mixer.txt, and verifying that the output appears
on that channel (the FX buses are numbered from 0 but JACK numbers
clients from 1). For example (from SB-Live-mixer.txt):
name='Music Playback Volume',index=0
This control is used to attenuate samples for left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
So "alsaplayer -o jack -d alsa_pcm:playback_5,alsa_pcm:playback_6"
should output to FX buses 4 and 5, which you can test by lowering the
'Music' control in alsamixer. With an SBLive, use ports 1 and 2 for the
front channels, 3 and 4 for the rear channels. The Audigy uses
different channels, see the above docs for more info.
In addition to multichannel recording applications, this should also be
useful for OpenAL implementations, which are currently restricted to
using 21 sources due to the use of an extra voice per stereo PCM. This
should allow up to 63 sources.
This also adds some new register info including a per channel half loop
interrupt that I have discovered by reverse engineering the Windows
drivers.
Improvements over previous versions:
- Routes the 16 channels to the 16 FX buses by default.
- Enables the first 16 FX capture outputs by default, required for
full duplex operation at latencies lower than 512 frames.
- Rewrote the voice allocator to use a more efficient round
robin algorithm, eliminating the need to reserve the
first 16 voices for the multichannel device. The next free voice
is maintained in the card record and the search starts from there.
- Use an extra voice for playback timing rather than the EFX capture
interrupt. I was only ever able to get that to work at 64 frames. Also
there are definite advantages to being able to use the capture and
playback devices independently.
- Use the newly discovered per-channel half loop interrupt source for
the extra voice rather than the channel loop interrupts. For unknown
reasons, this works better for multichannel playback, and does not seem
to affect regular PCM playback at all.
TODO:
- Fix the send routing and volume controls for the multichannel device.
The current (copy and paste) solution assumes either one or two voices
per PCM. So the default settings work fine but changing them with the
mixer is likely to have unpredictable effects.
- EFX capture should capture output channels 16-32 (mostly unused now)
by default, so that we only capture the sources the user has connected
to the multichannel recording inputs in the DSP manager. Typically FX
buses 0-15 would be connected directly to FX outputs 16-32 so the
capture channels would correspond directly to the playback channels. In
order for this to work the default DSP configuration has to be changed
slightly.
Lee
So.. exams gone OK this semester, so i'm returning to linux-audio world :)
unfortunately my tascam us122 still dont work, and the new jack backend
doesn't even compile to me.. dont know what to do.. but, since someone
is using this thing right now on linux, i think there's hope even for me :)
willy@Zeryn:~$ uname -a
Linux Zeryn 2.6.10-mm3 #1 Wed Jan 12 21:01:17 CET 2005 ppc GNU/Linux
willy@Zeryn:~$ cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.8rc2 (Wed Jan 05
06:44:40 2005 UTC).
willy@Zeryn:~$ jackd -d alsa -d hw:0
jackd 0.99.0
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
Sorry. The audio interface "hw:0" doesn't support any of the hardware
sample formats that JACK's alsa-driver can use.
ALSA: cannot configure capture channel
cannot load driver module alsa
willy@Zeryn:~$ cd Samples/HistoricalBeats
willy@Zeryn:~/Samples/HistoricalBeats$ aplay -v -D hw:0 amen.wav
Playing WAVE 'amen.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 0 'TASCAM US-X2Y' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tick_time : 1000
tstamp_mode : NONE
period_step : 1
sleep_min : 0
avail_min : 4096
xfer_align : 4096
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
willy@Zeryn:~/Samples/HistoricalBeats$
willy@Zeryn:~/Pacchi/jack-0.99.10.0usx2y$ ./configure
[...]
willy@Zeryn:~/Pacchi/jack-0.99.10.0usx2y$ make
[...]
make[3]: Entering directory
`/home/willy/Pacchi/jack-0.99.10.0usx2y/drivers/usx2y'
if /bin/sh ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I.
-I. -I../.. -I../../config -I../.. -I../.. -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -I../../config -I../.. -I../..
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -MT usx2y_driver.lo
-MD -MP -MF ".deps/usx2y_driver.Tpo" -c -o usx2y_driver.lo usx2y_driver.c; \
then mv -f ".deps/usx2y_driver.Tpo" ".deps/usx2y_driver.Plo"; else rm -f
".deps/usx2y_driver.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../config -I../.. -I../..
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -I../../config
-I../.. -I../.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -MT
usx2y_driver.lo -MD -MP -MF .deps/usx2y_driver.Tpo -c usx2y_driver.c
-fPIC -DPIC -o .libs/usx2y_driver.o
usx2y_driver.c: In function `alsa_driver_setup_io_function_pointers':
usx2y_driver.c:292: error: `sample_moveswap_dS_s16' undeclared (first
use in this function)
usx2y_driver.c:292: error: (Each undeclared identifier is reported only once
usx2y_driver.c:292: error: for each function it appears in.)
usx2y_driver.c:300: error: `sample_moveswap_dS_s24' undeclared (first
use in this function)
usx2y_driver.c: In function `alsa_driver_configure_stream':
usx2y_driver.c:334: error: `SND_PCM_FORMAT_S16BE' undeclared (first use
in this function)
usx2y_driver.c:334: error: initializer element is not constant
usx2y_driver.c:334: error: (near initialization for `formats[3].format')
usx2y_driver.c:334: error: initializer element is not constant
usx2y_driver.c:334: error: (near initialization for `formats[3]')
usx2y_driver.c:335: error: `SND_PCM_FORMAT_S16LE' undeclared (first use
in this function)
usx2y_driver.c:335: error: initializer element is not constant
usx2y_driver.c:335: error: (near initialization for `formats[4].format')
usx2y_driver.c:335: error: initializer element is not constant
usx2y_driver.c:335: error: (near initialization for `formats[4]')
make[3]: *** [usx2y_driver.lo] Error 1
make[3]: Leaving directory
`/home/willy/Pacchi/jack-0.99.10.0usx2y/drivers/usx2y'
[...]
willy@Zeryn:~/Pacchi/jack-0.99.10.0usx2y$
if someone has some clue... :)
thanx for the time spent reading this
wil
---
Il jazz e' lasciare che la luce brilli, lasciarla essere.
-- Keith Jarrett
Hi!
I did try the following things to get current cvs to work.
I used the appropriate configuration method and then edited the
Synthesizer.cpp and exchanged "ASM_X86_MMX_SSE" with "CPP" as in the other
synthesizer_mode functions. The sampler compiled cleanly. But when running it
(with OR WITHOUT the --no-tune option) it crashes after a few seconds. It
says:
Zombified - calling shutdown handler.
Then it keeps idling there. I have to use killall -9 linuxsampler to
terminate it. CTRL-C doesn't work.
Any idea. I use jack 0.99.47 (CVS from sunday.
Is there anything I can do to help find this "bug?"? Some debug information,
etc...
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide