hey list,
I've been struggling for the past couple of weeks trying to get my
netbook to perform well as a lightweight music workstation (mostly
synth work, light daw stuff). I'm getting many, many xruns, clients
getting kicked, etc. something is clearly not right. how do I begin
tracking down the source of xruns? I have an -rt kernel, a usb sound
card using -p256 -n3, running fluxbox with only wicd running to manage
my network. point is, I've tried the hunt-and-peck method and
(surprise) it hasn't done any good. how can I go about finding out
what exactly is tripping jack up, and what I can do to stop it?
(PS - I've said it before: maybe I'm expecting too much of a netbook.
could that be it?)
--
Josh Lawrence
http://www.hardbop200.com
So many times I'm sitting here with Jack running along with various apps
and I end up downloading an mp3 which to listen to I just want to type:
play downloaded.mp3
but I can't because Jack is running and Sox does not know Jack AFAIK.
Are there any similar command line programs for doing this through Jack?
I'm only interested in the play facility of sox.
Or a way to get round it?
Cheers,
James.
sound card: IntelHD
alsa version: 2.6.31-r6
pulseaudio version: 0.9.19
mpd version: 0.15.5
disto: gentoo amd64
Sound file format: Flac
Folks,
What i would like to be able to do is to play music files at their
native rates. I realize that my sound card's rates begin at 48khz, so
44.1khz files may have to be upsampled in any case. That's not
preferable but that's alright. However, i'd like to be able to play 96
khz files and 192 khz files at their respective rates with out resulting
to upsampling. If i have to upsample everything to 192khz to avoid
downsampling files to 48 khz i'll do that but it's not ideal.
So, i'm running an mpd player which feeds into pulse audio which feeds
into alsa. Do i need to configure all 3 to handle this or should it be
working "out of the box"?
I've looked around for some sort of display which will tell me at what
rate the files are being played in but i can't find one and i don't know
if for instance, mpd is passing them in 96 khz or 192 and pulse is down
converting, or if mpd and pulse are passing them in 96 khz or 192 and
alsa is down converting or something. How can i verify this is working
when it's set up? Going by ear may not be reliable.
Am i best off just setting up the system to upconvert to 192k? I think
that might cause distortion. Right? If so, i'd need set that up in mpd,
and pulse and alsa right?
Any ideas or pointers would be appreciated. I'll happily give more info
if wanted.
Thanks a lot,
--
Bearcat M. Şandor
Cell: 406.210.3500
Jabber/xmpp/gtalk/email: bearcat(a)feline-soul.net
MSN: bearcatsandor(a)hotmail.com
Yahoo: bearcatsandor
AIM: bearcatmsandor
Hi,
ams 2.0.1 has just been released.
tar.gzip and tar.bzip2 are available at
https://sourceforge.net/projects/alsamodular/files/
the NEWS:
========================================
ams-2.0.1 (2009-12-26)
Fixed Bugs
o Compile error for Qt 4.2 fixed
o Highlight MIDI controller in Control Center,
if MIDI event has been received.
o Fix crash unbinding multiple controllables connected to the
same midi controller.
o Initialized variable in env-module.
Fixes env-module mute bug discribed by lee(mrleelee).
General Changes
o MIDI channel numbering changed from 0..15 to 1..16.
ams-2.0.0 (2009-06-12)
New Features
o Redesign of 3D look
o Application icon
o German translation
o Keyboard shortcuts for menu and dialog items
o Menu item for recently opened files
o French translation (by Fank Kober)
o New --name command line option to specify the ALSASEQ/JACK
clientname
o Legato in monophonic mode using the "--poly 1" command line
option (by Atte Andre Jensen)
General Changes
o Port form Qt 3 to Qt 4.x library.
o A newly written autoconf/automake environment now provides the
usual "./configure && make && make install" comfort.
o Command line options are reworked.
- JACK now is the default interface, if the connection fails ams
connects to ALSA. This behavior can be modified using the -J and
-A options.
- The initial patch file to be loaded no longer needs the -l
option.
========================================
regards & merry xmess,
karsten
This is driving me nuts.
When I use the "-X seq" argument to JACK with JACK MIDI, it makes a bunch of bogus connections for EVERY synth, that get reported by ALSA via aconnect -lio,x and make it unreadable. i.e.
Connecting To: 128:0[real:0]
Connecting To: 128:0[real:0]
Connecting To: 128:0[real:0]
Connecting To: 128:0[real:0]
.... spam spam spam spam..... on every port, of every synth. On my setup, this line gets repeated 28 times.
We've got 128:0, we've got [real:0], we've got 128:0 and [real:0], we've got [real:0] and 128:0, we got.....
But I don't LIKE 128:0[real:0]!
In fact, there isn't any such synth! It doesn't exist at all, according to aconnect. I'm listing the available ALSA MIDI devices, and... other than 0: System, the synths start at 130. There is no 128. It is connected to nowhere. is a ghost device?
What's up with this? Is there a way to make it stop?
Thanks, and happy holidays.
-ken
This seems to be sort of a FAQ, because I've seen many places this is
discussed online, but no thread or blog post ever seems to quite reach
an answer, so I figured I'd ask...
Up until now, I've been terribly spoiled by Jack-aware applications like
Ardour that seem to be able to automatically find all the channels on my
Multiface and auto-name them as "playback" and "capture" channels 1
through 18. All this happens without me doing anything, so long as I've
got a properly configured realtime Jack daemon running, and the
Hammerfall mixer program is running, everything just works, which is
fine for programs like Ardour that understand how to talk to Jack
properly.
However, there are a lot of programs that only understand Alsa, and a
surprising number of programs that do compile against Jack but still
have Jack support that's very crude and doesn't actually work very well.
(There are even a few that can only be used on Alsa at all thanks to
Alsa's OSS emulation's fake /dev/dsp.) Currently, I'm dealing with the
former -- some programs that have Jack, but it's nearly useless because
the Jack support is so bad. I don't even need hard realtime from them.
I just want them to see the channels on the multiface and output audio.
>From what I've gathered online, I think what I need may be a .asoundrc
file. Then again, maybe not: The asoundrc documentation says that what
it's doing is basically mapping device/channel names found in
/proc/asound/devices (sort of the same info you get from 'aplay -L') to
custom names and routings. Problem is, the 18 channels of the Multiface
all show up as *one* PCM device here! Where are all my subdevices? For
that matter, if I did even try to use that one PCM, which channel would
it come out of? (Haven't tried it...not really that curious.)
Other people have asked this before, but most such threads seem to
always come to "just use Jack." Is it impossible to directly access
these devices from Alsa? I'm not wanting anything fancy here. If I do
have to write a .asoundrc, where do I get the information that HDSPMixer
seems to innately know about how my channels map to the hardware so I
can create one?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
Greetings,
A quick note of deep gratitude to all Linux audio users and devs from
whom I have learned and continue to learn so much.
Thank you, and I hope you all enjoy the best of the holiday season.
Best,
dp
I think I've got it :-) Muchas gracias to Joakim Hernberg, who posted
the jack2 profiling document. I read it about five times, trying to
ponder what my first step might be given that info. It discusses two
major modes of jack2: the default, which is asynchronous, and another,
which is synchronous. Under asynch, my stress-test yields zero xruns
(or close) at 5.3 ms (as reported in Qjackctl); but under synch, my last
two tests say kosher at 0.667 ms *grin* Shocking. That synch makes a
whole lot of difference. I can just imagine jack2 jockeying all four
CPUs to make that happen :-) I'll be doing a lot more stress-testing to
prove it, but for right now, frames/period are 64, sample rate 192000,
two periods/buffer :-) :-) I praise the Lord, and I thank everyone for
the help!
J.E.B.