drew Roberts wrote:
> On Tuesday 19 May 2009 09:48:11 Fons Adriaensen wrote:
>
>> On Tue, May 19, 2009 at 08:40:58PM +0700, Patrick Shirkey wrote:
>>
>>> Krzysztof Foltman wrote:
>>>
>>>> Ideally, jackdbus shouldn't even allow jackd binary to
>>>> exist in $PATH (and vice versa), to prevent the exact
>>>> kind of situation that Fons is experiencing.
>>>>
>> Programs that do that kind of things have a name
>> here: malware. I'm the boss on my system, and I
>> will decide what goes into $PATH. Just as I decide
>> which filesystems get mounted and where, and how
>> permissions are set.
>>
>
> Fons, I think some people have misunderstood some things you have said in this
> thread. In this case I think you misunderstood Patrick. (Or I did - not a bad
> possibility.)
>
> I think what he was saying was that jackdbus would check for jackd in $PATH
> and complain bitterly / refuse to sintall / whatever. Not that it would try
> and control what $PATH was set to. Or perhaps you got that and I
> misunderstood your objection.
>
Hi Drew,
If you are referring to me, then I would like to remove myself from the
dbus issue. I am currently concerned about PA usage for non technical
users and/or "Ralf Maldorf's" attitude towards Linux Audio as a platform.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
> If there is proper understanding and objections / differences still remain,
> that is one thing. So often in life we are disagreeing with what we think
> people mean when if fact we may agree with what they actually mean.
>
>> Ciao.
>>
>
> all the best,
>
> drew
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
Robin Gareus wrote:
> Hi guys,
>
> Ken Restivo wrote:
>
>> [..]
>>
>
>
>> I still think it'd be more productive to improve AZR3, or to build
>> something new out of DSSI/LADSPA/LV2 plugins, than to try to convince
>> some guy to change the license on what is essentially an orphaned
>> proprietary product.
>>
Imo it's to early for this conclusion. There is no reply from the guy...
>
>
> if Frederik sticks to his ugly license.
>
Please wait for the justement call till the guy has responded and let
him be free to choose the license he wants for his software.
\r
Hello
I've been having a problem which isn't directly to do with audio—it's to
do with the Ubuntu realtime kernel—but I haven't got any answers from
the Ubuntu forums and this is a real showstopper as far as doing audio
work goes.
I hadn't done any audio work for quite a while, and therefore had been
running the 64 bit Intrepid generic kernel on my Thinkpad R61i without
too much problem (but not entirely without problems either). Yesterday I
booted the realtime kernel. When I tried to suspend the machine I got a
message "Freezing of tasks failed after 20.00 seconds (2 tasks refusing
to freeze):" At this point the interface had frozen completely and I had
to force a shutdown by holding down the power button. There was however
some intermittent flickering from the disk activity indicator, so
something was still working. The tasks that were refusing to freeze were
NetworkManager and wpa_supplicant.
This happened one or two more times. Then I tried it again and found
that 4 tasks this time were refusing to freeze: NetworkManager,
wpa_supplicant, avahi-daemon and gnome-do. After this I returned to the
generic kernel, which is working as well as it always did.
Any ideas what's going on here? Unfortunately upgrading to Jaunty is not
a viable workaround yet because of its broken Intel graphics driver.
Many thanks
Robert
Hi all,
Just bought a neat-o Behringer USB adaptor, UCA202.
I can't seem to get capture working. A quick googling shows a few happy users.
There is *no* volume control listed in alsamixer for the capture device, however it is definately recognised.
Qjackctl shows following devices (both in capture and playback:
hw:1 usb Audio CODEC
hw:1,0 usb Audio
Capture device shows up in /proc:
shane@viejo:~$ cat /proc/asound/card1/pcm0c/info
card: 1
device: 0
subdevice: 0
stream: CAPTURE
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1
shane@viejo:~$ cat /proc/asound/devices
2: : timer
3: : sequencer
4: [ 1- 0]: digital audio playback
5: [ 1- 0]: digital audio capture
6: [ 1] : control
7: [ 0- 1]: digital audio capture
8: [ 0- 0]: digital audio playback
9: [ 0- 0]: digital audio capture
10: [ 0] : control
Anyone got a clue???
- shane
Another version of Ecasound/Nama is available at CPAN
for your multitrack recording pleasure. We are
approaching a 1.0 release!
Here are the newest changes:
- Track soloing
- Documentation rewrite
- Pager for long text listings
- Many bug fixes
- Simplified build script (preprocessing really) facilitates
source browsing/tinkering
And a feature list:
- Based on Ecasound, a stable, full-featured audio
processing engine.
- Very flexible template-based signal routing allows for
multiple buses. Possible to simultaneously record and
mixdown a live performance.
- Tracks
+ can be mono, stereo or any desired width
+ volume/pan with any number of effects
+ signal sources from soundcard or JACK clients
+ multiple WAV versions per track
+ playat, reverse, select, audioloop
- Tk based GUI
+ main window and effects window
+ auto-hinting of LADSPA plugin parameters range and linear/log
+ stable, lightweight
+ no dialog boxes considered a feature
- Full-featured text UI
+ Executes Ecasound commands, Nama commands, shell commands
and perl code
+ multiple commands per line
+ help for commands and plugins
- Automated connection to JACK clients
- Marks
- Looping over entire chain setup between designated marks
- Full diagnostics with dumping of all data structures
- Persistent settings stored as browsable YAML
- Per-project configuration files
- Small codebase compared to other projects, ~7K lines
- Active development
- Hackable, extensible
Caveat! We're having some difficulties compiling
Audio::Ecasound, on which Nama depends, for x86-64.
The easiest way to install Nama is from CPAN:
cpan Audio::Ecasound::Multitrack
If you'd prefer to install from sources, you can copy the
repository thus:
git clone git://github.com/bolangi/nama.git
Build instructions are found in the README.
I'm interested in any comments, bug reports, feature
requests, etc. you may have.
Regards,
--
Joel Roth
Hi @LAU people,
I would like to open a discussion about the MIDI capabilities of LAU
applications here.
There is quite a number of great LAU software of course and we have seen
frequent announcements of new versions or even complete new applications.
But from a particular point of view their use sometimes is a bit limited.
I have found that most applications require the user to work (record, program,
finetune etc.) from behind the computer on which the application runs. But that
limits the usability in case someone is actually playing an instrument with
MIDI interface, especially in a live playing environment, and needs something
more convenient to handle parameters etc.
I have seen few applications that allow for using MIDI commands let alone
allow me to enter a custom made (be it SYS EX message or any controller
message) MIDI message to trigger a particular action within the application.
There have been a number of hardware controllers available for some time that
come with numerous drawbars, pushbuttons and similar stuff to ease controlling
mixer applications, drum applications or anything else, so having a flexible
MIDI input interface (software) seems to me to be a really great idea.
At the moment things I would like to do force me to use a MIDI programming
language instead of using all these new fancy GUI applications with much more
and much better options apart from their MIDI support than the simple
programming environment has. I have to program nearly everything on my own.
And I find myself running against walls because there are just too many things
that simply do not work.
I wonder if noone else has a MIDI "Start/Stop" feature on their wishlist for
their favourite drum computer program, or "Fill
1/Fill2/Ending1/Ending2/Variation" etc. (which applications like hydrogen do
not yet have but they are on their way).
I wonder if noone else prefers a real hardware turning knob over a GUI mouse
slider (which cannot be moved from keyboard, as there is no MIDI controller
input for the slider...).
What do You think? Anything worth adding for You here? Is better MIDI input of
applications worth asking for?
Would like to learn more...
Regards,
Crypto.
Issue was solved. For anyone's future reference:
Define pcm and ctl devices in .asoundrc, use the hw:1 "CODEC" device, not the hw:1,0 subdevice for Jack.
For output volume control need to define a softvol control in .asoundrc
It sounds quite acceptable, BTW.
- shane.
2009/5/18 <hollunder(a)gmx.at>
> Can I evaluate it by recording an Album with it and see how my audience
> likes it?
>
> Regards,
> Philipp
>
Hah, good one!
William M. Quarles wrote:
> TheOther wrote:
>>> David, or Fernando, or ANYBODY else out there, do you have any idea why
>>> this isn't working for me? Something smells funny about Pulseaudio, but
>>> I don't know enough about it to be able to say why.
>> Hello William,
>>
>> You can check the PlanetCCRMA archives to see my thoughts and
>> experiences with PulseAudio.
>>
>> If you have Fedora 10 installed, remove PulseAudio.
>>
>> If you are using Fedora 7, 8, or 9, then upgrade to Fedora 10 so you
>> can remove PulseAudio.
>>
>> Good Luck,
>> Stephen.
>
> Sounds good to me, I don't even know what PulseAudio does other than it
> kept Rhythmbox from working when I first installed Fedora 10 on a
> computer. But what dependencies will I be breaking? Last time that I did
> that, I also found like a dozen or so other applications that depended
> on PulseAudio that my RPM database apparently didn't know about.
>
> I'll give it a shot!
>
> Thanks,
> William
I went from Fedora 6 (no PulseAudio) to Fedora 9 (PulseAudio). Under
Fedora 9, trying to remove PulseAudio also removed KDE and Gnome.
That was unthinkable. In Fedora 10 you can now remove PulseAudio
without problems.
If you have Fedora 9 (and probably this will work for Fedora 7 and 8),
enter your hardware BIOS at bootup time and disable the motherboard
sound chip. Leave PulseAudio installed.
In this case the PulseAudio server fails to start. Your audio
applications will then use ALSA, OSS, Jack, or whatever else you are
using for sound. For me, my problems were solved. My PCI sound card
was recognized as the default, and the Linux applications that are
hard coded for the default sound device worked with my PCI sound card
as expected.
From this (disabling the motherboard sound chip) I inferred that
PulseAudio was developed as a means for helping Windows users transfer
to Linux in a painless manner. I'm assuming PulseAudio was never
intended to be useful for advanced Linux audio users, because it
wasn't checking for additional sound chips/cards/devices *and*
allowing the user to specify the order in which those sound
chips/cards/devices would be used. PulseAudio always defaulted to the
motherboard sound chip, and a fair number of Linux sound applications
always default to the default sound chip/card/device (which in the
case of PulseAudio will be the motherboard sound chip.) Hence, you're
having all this trouble in trying to use a special video/audio card
because PulseAudio and very likely your sound application are only
trying to use your motherboard sound chip, since that is the default.
Hope this helps,
Stephen.
Greetings,
I was surfing YouTube and found this video :
http://www.youtube.com/watch?v=2pzxRU6wTh8
I'm the guy on the right. :)
Seven years ago, wow. Time is flying.
Best,
dp