Does anybody have a valid download link for the Steinberg VST SDK? I need the
headers to compile fst, but the Steinberg people seem to be playing
sillybuggers with their website and the old links don't work anymore.
Many thanks.
Robert
--
Robert Persson
ireneshusband(a)fastmail.fm
YahooMess:ireneshusband AIM:shamanicpolice
56% of US Gulf War I veterans have chronic health problems. The disability
rate after Vietnam was 10%. For other 20th Century wars it was 5%.
What has become of "Wired", the loudly touted "Next greatest audio app"
in Linux? There were several hard and fast releases last November and
updates in December then...
And should someone from the development team be on the list...nice
looking interface...But Puhleeeeeze use Jack for audio interface or add
it to the list of already available options. I know it uses Port audio
but I have not been able to figure out what the heck Portaudio is let
alone how to get it working!
R~
Hi
http://www.alsa-project.org/~iwai/OSS-Emulation.html states that
echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss
should enable direct mode. But when I run
echo "csound 3 128 direct" > /proc/asound/card1/pcm0p/oss
(which works) what does the numbers "3" and "128" mean and what would be
sensible values? I know it's something to do with buffers size, but
that's not enough. Also what would such numbers convert to in terms of
latency?
Thanks in advance...
--
peace, love & harmony
Atte
http://www.atte.dk
This is from Lamont Dozier's "Fish ain't bitin'" (1973) Can someone
explain the expression "The short is off the stick"? Thanks.
And meanwhile in DC
Tricky Dick is trying to be slick
And the short is off the stick
Because I'm gonna get it
Tricky Dick, please quit
There's a story attached: Dozier's record company (ABC) published a
letter from Nixon's administration complaining about the single. Boosted
the song into top 10.
Wolfgang
Hi.
Being quite a newbie to audio on Linux, I am trying to
get rid of xruns when I record using ardour and jackd.
I start jackd with
jackd -d alsa --device hw:1 --rate 44100 --period
8192 --nperiods 2
but this max. buffer size is still not enough to
completely prevent xruns. I see xruns often when I
switch between windows and so thought that this is
caused by Xfree86 stealing CPU from jackd, since
xfree86 runs with nice factor -10.
I tried to run jackd as root so I could use the
"--realtime" option but my system is then sadly
reduced to a thrashing heap of rubble.
After loading a recorded session (approx. 45 minutes
of audio - 830 MB data) "top" tells me that
ardour is using 69.5 %MEM
jackd is using 25.6 %MEM
and the loading of the session has taken several
minutes due to thrashing (kswapd is on heavy work here
according to "top"). The system is very unresponsive
and I am unable to use ardour for anything useful.
If I don't use the "--realtime" option, "top" says
ardour is using 20.4 %MEM
jackd is using 2.1 %MEM
after the session is loaded (in 2-3 seconds), and the
system runs quite well (except for the occasional
xruns of course).
Is "--realtime" forcing jackd and its clients to lock
all of their memory in RAM ? I would then need quite a
lot of RAM to use the "--realtime" option. Is it
really necessary to use _that_ much RAM ?
I also tried to renice jackd with -20 so it runs with
priority 0. Will the "--realtime" option give me
better stability than the renicing ?
Cheers
-- Jan Holst Jensen, Copenhagen, Denmark
____________________________
System info:
Debian Sarge with a custom-built unpatched kernel
2.6.10. Kernel config includes "Pre-emptible kernel"
and pure ALSA - no OSS emulation.
Compaq Evo N400C laptop. 700 MHz Pentium III with 128
MB RAM. I know this is not top-of-the-pops but I have
used it for two years to do stereo recording and
8-track mixing on Windows 2000 quite nicely.
jackd version:
bonham:~# jackd --version
jackd version 0.99.0 tmpdir /dev/shm protocol 13
bonham:~#
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Hi,
I'm using ardour to record and I have recorded my songs at 44100 until
now. Now I want to switch to 48000.
What's the easiest way (always within the best way to do it) to convert
my sessions to 48000?
I would like something automatic like running a script before starting
an ardour session at 44100 or clicking some option at ardour to import it.
I have googled this issue and I found:
http://sr-convert.sourceforge.net/
but it's not debian-packaged yet and I'm too lazy now...
maybe ecasound? but I'm afraid it doesn't consider so much things as
sr-convert...
I upgraded my debian testing and now MIDI doesn't work anymore.
Before I could load soundfonts normally and now I get:
marc@marcbcn:~$ sfxload
No AWE synth device is found
any clue about how to solve it? (google wasn't enough...)
thanks in advance,
I wouldn't be a debian user without such great mailing lists as LAU and
debian-users...
YES!!! YAY YAY!!
VICTORY TO THE MASSSESS!!!
> I'm using the HDSP 9652 constantly under FC2/Planet and have no
> problems what so ever. The card is working well. hdspconf allows me to
> set it up as either a master or slave in terms of clocking, and
> hdspmixer works great for routing audio and checking levels.
>
> I have no issues with this card anymore under Linux.
>
> Cheers,
> Mark
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
> > I'm going to buy one of these cards, and I was wondering what about the
> > differences from one to each other and concernig ALSA's support.
> > By ALSA's website seems they are completly supported, but I would like
to
> > have some users' confimations.
>
> hey there - i have the HDSP 9652 and love it - it was a bit of a pain to
get
> it really working at first, because there was a driver issue that we (the
> linux audio community in general) were having a hard time ironing out.
the
> issue didn't exist with the digi9652 card that was almost exactly the
same,
> just the HDSP 9652
>
> in reality though you have to consider what other gear you have - the 9652
> was necessary for me because I needed it to interface via ADAT light pipe
to
> 24 channels on my digital mixer. But if I didn't have the digital mixer
to
> do my A/D conversion, the 9652 would've been wrong because it doesn't have
a
> breakout box with analog inputs like the multiface or something else -
the
> HDSP 9652 has 24 channels optical i/o and a stereo spdif - that's the only
> in and out of that card...
>
> TotalMix doesn't run under linux, it doesn't matter. Under linux, you'll
be
> using a program called hdspmixer - it's the exact same thing (am I
> remembering that right? yes I think so)
>
> what is your studio/other gear situation like?
Hi Aaron,
I will use the HDSP mainly with adat I/O and s/pdif I/O, so I think it's the
right choice.
Could you please be more detailed regarding HDSP 9652 problem?
Thanx!
Michele