Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by drew Roberts

Ignorant here. Trying to scrounge around and make something work for a demo purpose. In python I am trying to build this pipeline: pipeline_txt = ( 'jackaudiosrc ! ' 'level name=level interval=1000000000 !' 'jackaudiosink') pipeline = gst.parse_launch(pipeline_txt) I have been trying that a number of ways. So, I basically watch the bus for level info. In a subroutine, I can print the peak info to the terminal. I can't seem to figure out how to pass this info back to the rest of the program so that I can hook it up to a graphical meter. Cna anyone point me to some simple code doing something like this? Give me some clues that might help someone who seems to be being very dense for days now? all the best, drew

12 years, 10 months

Floss alternative to red5

by APO33

Hello all, we are working on some development of audio/video web live applications at the moment. We are facing a little problem, maybe some people here already came across. Some people advised us to use red5, an audio/video streaming and multi-user solution to take sound from mic / sound card input + webcam/cam to be streamed online via your browser. The biggest problem we are facing is that is based on adobe closed flash system and it use only proprietary format/codecs such as mp3, flv and h264 :-( We are looking for a way to do the same with floss technologies such as ogg, theora, icecast or others... The idea is that the final user will stream his sound and video with his browser and everyone could see/hear him and do the same via their browser. We are actually testing some solutions with gstreamer but we still need an external client, although we are thinking about using some python script to run on the server to handle gstreamer live stream... but we are not sure... Anyway if any of you have any hints or some floss solutions for that, it would be really highly appreciated :-) thank you cheers Julien -- APO33 space of research and experimentation http://www.apo33.org info(a)apo33.org

12 years, 10 months

Re: [LAD] Puredata slow response

by Ivica Ico Bukvic

Not sure if this is going to help but I did notice with pd-l2ork on a laptop with an AMD video card (fglrx driver) when I have the tearfree (vsync) option enabled pd-l2ork's gui gets very sluggish. Disabling the vsync option makes it fine. On Feb 24, 2013 3:54 PM, "Fons Adriaensen" <fons(a)linuxaudio.org> wrote: Hello all, I'm seeing a strange probelm with Pd. I'm testing a very simple patch (total CPU load < 1.5% with DSP enabled). There are a few message boxes used to set a hslider to some preset values. With DSP enabled they take something like a second to respond to a click. What's wrong here ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

12 years, 10 months

sound/usb: Add support for Steinberg UR22 audio interface.

by Clemens Koller

This USB-Audio/MIDI-Interface is based on a Yamaha YC706A0 ASIC. Signed-off-by: Clemens Koller <clemens.koller(a)embeon.de> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index c39f898..d18429a 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -353,6 +353,36 @@ YAMAHA_DEVICE(0x105d, NULL), } } }, +{ /* Support for Yamaha YC706A0 chipset based Steinberg UR22 audio interface */ + USB_DEVICE(0x0499, 0x1509), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + /* .vendor_name = "Yamaha", */ + /* .product_name = "Steinberg UR22", */ + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 3, + .type = QUIRK_MIDI_YAMAHA + }, + { + .ifnum = 4, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = -1 + } + } + } +}, YAMAHA_DEVICE(0x2000, "DGP-7"), YAMAHA_DEVICE(0x2001, "DGP-5"), YAMAHA_DEVICE(0x2002, NULL),

12 years, 10 months

Interoperability between session management systems

by Johannes Kroll

A couple of days ago, I tried out non-session-manager, and thought, this is really nice. It really works in a practical, easy way. Unfortunately the number of apps supporting non-session is quite small (as is the case for *all* session management systems, AFAIK). There may be "a complete audio studio" supporting non-session, from one choice of sequencer to one synth to one sampler, but people like to use their favorite software. You can't just say, "if you want to use a sequencer, use X because it supports non-session". So its usefulness is limited. However, many apps support one session management framework or the other. So the obvious thing to do if you want to give people more choices would be to create some kind of interoperability layer between session management systems. What do you think about this? Is there an effort for something like this already underway? I personally think a good first step might be to create some compatibility between non-session (because I like it) and jack-session (because most people are using jack).

12 years, 10 months

Puredata slow response

by Fons Adriaensen

Hello all, I'm seeing a strange probelm with Pd. I'm testing a very simple patch (total CPU load < 1.5% with DSP enabled). There are a few message boxes used to set a hslider to some preset values. With DSP enabled they take something like a second to respond to a click. What's wrong here ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

12 years, 10 months

Joining LAD and LAU lists (And: more central instances in a "herding-cats" community are good)

by Nils Gey

Hello both lists, I see the reason for a non-discussion announcement list, LAA, but is it really necessary to have twp lists? I know there are several people who only subscribed to one list, but I don't know if this is intentional or not. Why not merge both. The immediate effect would be a stop at the cross posting just to reach the whole community. The mailinglists are from the same service, but I think in the end it would be more convenient and better for everyone to have it all in one place. Yes, I know some of you fear (mostly people in the dev list who do not read LAU) that they will get unwanted mails. But as you can tell from experience topics like "why linux audio sucks", "water as fuel" and other mega/nonsense/offtopic threads get cross posted anyway. And I know some of you think devs and users should be kept seperated. But be honest: Who in the world is subscribed to a linux mailing list and could not stend the occasional developers topic. If you want beginner-level support you most likely don't know how to use lists :) Just to be clear: I am a friend of diversity and seemingly "redundant" applications and projects. There cannot be enough sequencers, samplers, synthesizer, notation programs etc. But when it comes to infrastructure and core building blocks I see no sense in seperation. This is the strong point, compared to other operating/eco-systems. We may friendly compete on a musical or feature basis, but there is no need to border a program just to make it harder for the users to use the program of the "enemy" (from a Windows/OSX POV). In a Linux-Audio world of diversity and individuality, it is good to have central places and instances. We can do whatever we want but unlike the closed source world we have no need to create factions and standards that rival with each other, creating artificial gaps. The most successful of these instances is JACK itself. A centralized audio server, hailed and praised by everyone. And since I am writing this mail already, my personal wish list: Please join the two blog/RSS planets as well (http://www.planet.linuxmusicians.com/, http://linuxaudio.org/planet/ ) Merge Yoshimi and ZynAddSubFx, the JACK versions and experimental forks, the session managers/protocols and a few audio distributions which have not enough manpower and that can be used to boost the other distributions. "Joining/Merging" also can mean for one side to step down honorable and retire the project. Nils http://www.nilsgey.de

12 years, 10 months

[ANN] MFP 0.01 (Music For Programmers, a graphical patching system)

by Bill Gribble

MFP -- Music For Programmers Release 0.01, "Mining For Participants" MFP is an environment for visually composing computer programs, with an emphasis on music and real-time audio synthesis and analysis. It's very much inspired by Miller Puckette's Pure Data (pd) and Max/MSP, with a bit of LabView and TouchOSC for good measure. It is targeted at musicians, recording engineers, and software developers who like the "patching" dataflow metaphor for constructing audio synthesis, processing, and analysis networks. MFP is a completely new code base, written in Python and C, with a Clutter UI. It has been under development by a solo developer (me!), as a spare-time project for several years. Compared to Pure Data, its nearest relative, MFP is superficially pretty similar but differs in a few key ways: * MFP uses Python data natively. Any literal data entered in the UI is parsed by the Python evaluator, and any Python value is a legitimate "message" on the dataflow network * MFP provides fairly raw access to Python constructs if desired. For example, the built-in read-eval-print console allows live coding of Python functions as patch elements at runtime. * Name resolution and namespacing are addressed more robustly, with explicit support for lexical scoping * The editing UI is largely keyboard-driven, with a modal input system that feels a bit like vim. The graphical presentation is a single-window style with layers rather than multiple windows. * There is fairly deep integration of Open Sound Control (OSC), with every patch element having an OSC address and the ability to learn any other desired address. The code is still in early days, but has reached a point in its lifecycle where at least some interesting workflows are operational and it can be used for a good number of things. I think MFP is now ripe for those with an experimental streak and/or development skills to grab it, use it, and contribute to its design and development. The code and issue tracker are hosted on GitHub: https://github.com/bgribble/mfp You can find an introductory paper (submitted to LAC-2013) and accompanying screenshots, some sample patches, and a few other bits of documentation in the doc directory of the GitHub repo. The README at the top level of the source tree contains dependency, build, and getting-started information. Thanks, Bill Gribble

12 years, 10 months

ice1724, external synchronization

by Andrew Gaydenko

Hi! Is it possible to use ice1724 card with external synchronization via SPDIF input? How to? a

12 years, 10 months

Re: [LAD] avw lv2 plugins with Ardour 3 on KX Studio

by Aurélien Leblond

Hi Kane, These plugins were especially written to be used with Ingen. Now, you will need a quite recent version of Ingen to enjoy them. I believe KX Studio has a repository for software in development, and the latest version should be in there. Let me know if that helps. Aurélien On Feb 19, 2013 10:29 PM, <wolfbiter(a)gmail.com> wrote: > Ok thanks for letting me know. I'm assuming you guys use these plugins - > what programs do you run them with? > > On Mon, Feb 18, 2013 at 10:57 AM, David Robillard <d(a)drobilla.net> wrote: > >> On Mon, 2013-02-18 at 17:25 +0000, Aurélien Leblond wrote: >> > Hi Kane, >> > >> > I believe this issue is due to the fact that Ardour doesn't support CV >> > port (it is the same in Jalv). >> > >> > In these plugins, the CV Port are used to control when the Beat >> > Repeater/Slicer would be repeating/slicing. >> > >> > @David: Can you confirm? >> >> Correct, neither support CV ports at this time. Doing so would probably >> not be a big deal, I just haven't bothered yet since very few plugins >> that are suitable for use in such hosts use them yet anyway. >> >> Not a big deal to do the trivial clunky ControlPort equivalent thing >> anyway. When automating Ardour could/should 'render' a sample accurate >> version of the curve for such ports, but that would be a bit more work. >> >> -dr >> >> >

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev