Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Paul Davis [mailto:paul@linuxaudiosystems.com] > > > that's ok, I don't think everything has to be > understandable by a newbie, > >it's not the wording of what's there that is a problem, it's > the missing > >information that's a problem (I just sent an update about > what functionality > >I have found missing in sb live, I guess more of that should > be available > >(for other cards) as well). > > just as a sort-of aside, i would note that a discussion on the > vst-plugins list right now points out that the windows creative > drivers for the audigy *do not* work in ASIO mode with ACPI turned > on. to make them work, its necessary to "install the drivers in > standard mode", whatever that means. and I can't make rca inputs work in windows as well:-) in fact they work even less than in linux - in linux the sound at least gets through the card and I can hear it (not record it though) but in win98 they seem to be completely dead. > this information is not available on the creative web site. ALSA is > not alone in this type of failure to document missing or incorrect > functionality, and our existence as an open community makes it more > likely that, with the correct documentation infrastructure, we can > ensure that it gets added in a timely way. yes, and to prove it I have already send an update and it's already on the page! erik

22 years, 10 months

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Patrick Shirkey [mailto:pshirkey@boosthardware.com] > Sent: Wednesday, October 23, 2002 1:49 PM > To: linux-audio-dev(a)music.columbia.edu > Subject: RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] > hel p for a levelmeter] > > > > this is what's on the page: > > >Creative Labs | Soundblaster Live Platinum | EMU10K1 | Install | > >(4)[A][B] > > > bottom of the page: > > > >(4) Hardware mixing supported > > > >... > > > >NOTE: Just because an I/O is listed does NOT mean it is > guaranteed to > >be supported. Please check the mailing > >list archives before making purchase decisions based on > requirements > >forIEC958 or ADAT I/O. > > >[A] IEC958 RCA Input > >[B] IEC958 RCA Output > > >which does not have a lot of informational value (I know > what it does > >not mean but what does it mean?) and it definitely does not imply > there >is a problem of getting the docs to support certain > functionality. > > Hmm. It has a certain informational value although I will yes, but not useful when choosing sound card (as it appropriately says:-) - which was my point. > I'll try to think of a way to word it for users who may not have the > requisite knowledge. that's ok, I don't think everything has to be understandable by a newbie, it's not the wording of what's there that is a problem, it's the missing information that's a problem (I just sent an update about what functionality I have found missing in sb live, I guess more of that should be available (for other cards) as well). > Apart from that at the top of the page it's explicitely > stated that some > companies have not provided the required docs to enable > support for a > device. I have always noticed those comments however it may yes, but saying 'some companies' has close to no informational value. knowing WHICH companies is crucial. > just be my > angle on things. I have made some changes to the matrix to be more > obvious that even if we have the docs we may not have all the > necessary > parts. Although I would've thought that most people already know that > about Linux hardware support. again, having general knowledge is of no use... what does it help a user to know that _some_ cards are better supported and _some_ manufacturers offer better/worse docs? One needs to know the _specifics_ which are close to impossible to find. > As you know the known bugs section in the driver notes gives explicit > information about things that we know do not work. I'll look making a > form for adding specifically to this file. IMO it would be much better if the link to details about the card would not say "Install' but instead indicate that details about the card can be found there (alsa soundcard matrix), I mean the column is named appropriately drivers&docs but the item in column is always 'Install'. It has mostly install info but also module options, known bugs etc. > I would like to do that and also make it easier for people to > post info > about supported devices. I have most of the work done but not > finished > yet. As it is I currently stay up to 6:00 in the morning many > nights of > the month. I'm lucky though as I only have to work 16 hours a > week in my > paying job. I could be working many more hours but have made the > decision to sacrifice some of my current earnings in order to build > Boost Hardware and DJCJ. Along the way I have also picked up > the alsa > website :) it's very important work and I hope that you'll bring it up so that it's actually a good resource for information (at this point it's IMO in the 'almost' category (mostly speaking of soundcards I use, not sure how much information there is for other soundcards)). thanks a lot for doing it! erik

22 years, 10 months

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Paul Davis [mailto:paul@linuxaudiosystems.com] > > [ re: OSS ] > > >> code. It will > >> soon be available only through emulation. It forces use of > >> the blocking > >> model. > > actually, it doesn't. nothing would stop the implementation of an OSS > driver/client for JACK. > > >> ALSA is very powerful and complete, but very complex. > This will make > > > > <rant> > > > > it is also pretty much useless for general users. I mean > if I can't listen > >to mp3 and browse the web at the same time ... (without > sound servers which > >were discussed recently and as far as I can tell the general > consensus is > >that they are bad and not to be used). Is there any rationale for the > >blocking behaviour? I mean I can't imagine situation where I > would want > > to clarify: the "blocking model" that joshua was describing has > nothing to do with the "blocking behaviour" that you are describing. > jaroslav (aka "mr. alsa") has justified the block-on-open model by > reference to POSIX standards for the open system call. its a bit > debatable, but his point of view on it is at least as close to > standard POSIX behaviour as yours. applications can avoid this quite > easily using O_NONBLOCK in the OSS open call (or its equivalent for > ALSA), later followed by fcntl(2) if necessary. > > i personally it would have been better to make open return EBUSY, but > the problem is that there is no flag for open(2) that says "block even > if busy", so with that design there is no way to get "block-on-open" > if desired. IMO it does not matter how well justified it is by POSIX or whatever else if the end result is unusable system. In case of 'file' files it makes (some) sense to block, however in case of sound I can't really think of realistic situation where I would want to block. It's either busy (and let program handle that) or realtime mixing should be offered. If they are concerned about POSIX that blocking could be defualt, user would be able to change it to either non-blocking returning EBUSY or non-blocking real time mixing (sw, if card does not support it in hw) anyway, thanks for background info. > > except of the blocking of sounds (the problem mentioned > above) I am quite > >dissapointed by functionality of linux drivers I have tried, > I have sb live > >platinum and (last time I checked): > > "i am quite disappointed that a group of volunteers who work for no > monetary compensation have failed to implement all the features i > want. i haven't offered to pay them, but i really hope they get all > these features working really soon because its really irritating not > being able to ..." well: - let's kill the messenger, - that's what open source promises. erik

22 years, 10 months

Re: [linux-audio-dev] soft synth as a plugin

by nikodimka

Guys, This answer appeared just after I decided to ask the very same question. Is it true that there is no _common_ "instrument" or "synth" plugin API on linux? Is it true that there is no the same kind of media for out-of-process instruments? I see that there are some kinds of possible plugin APIs: -- MusE's LADSPA extensions -- mustajuuri plugin -- maybe there's some more (MAIA? OX?) -- I remember Juan Linietsky working on binding sequencer with softsynths But I dont remember to hear anything about the results So can anyone _please_ answer: What is the right way to use the multiple (e.g. thirty) softsynths together simultaneously with one host? I mean working completely inside my computer to have just one (or even none) midi keyboard as input. So all the synthesys, mixing, processing goes on inside. And to send one audio channel out to any sound card. thanks, nikodimka =======8<==== Tommi Ilmonen wrote: ===8<================= Hi. Sorry to come in very late. The Mustajuuri plugin interface includes all the bits you need. In fact I already have two synthesizer engines under the hood. With Mustajuuri you can write the synth as a plugin and the host is only responsible for delivering the control messages to it. Alternatively you could write a new voice type for the Mustajuuri synth, which can lead to smaller overhead ... or not, depending on what you are after. http://www.tml.hut.fi/~tilmonen/mustajuuri/ On 3 Jul 2002, nick wrote: > Hi all > > I've been scratching my head for a while now, planning out how im going > to write amSynthe (aka amSynth2) > > Ideally i don't want to be touching low-level stuff again, and it makes > sense to write it as a plugin for some host. Obviously in the Win/Mac > world theres VST/DXi/whatever - but that doesnt really concern me as I > dont use em ;) I just want to make my music on my OS of choice.. > > Now somebody please put me straight here - as far as I can see, there's > LADSPA and JACK. (and MuSE's own plugins?). Now, I'm under the > impression that these only deal with the audio data - only half what I > need for a synth. Or can LADSPA deal with MIDI? > > So how should I go about it? > Is it acceptable to (for example) read the midi events from the ALSA > sequencer in the audio callback? My gut instinct is no, no, no! > > Even if that's feasible with the alsa sequencer, it still has problems - > say the host wanted to "render" the `song' to an audio file - using the > sequencer surely it would have to be done in real time? > > I just want to get on, write amSynthe and then everyone can enjoy it, > but this hurdle is bigger than it seems. > > Thanks, > Nick > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > Tommi Ilmonen Researcher >=> http://www.hut.fi/u/tilmonen/ Linux/IRIX audio: Mustajuuri >=> http://www.tml.hut.fi/~tilmonen/mustajuuri/ 3D audio/animation: DIVA >=> http://www.tml.hut.fi/Research/DIVA/ __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com

22 years, 10 months

Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone (fwd)

by Tim Goetze

apologies if this reaches you twice, it seems to have been swallowed by that big black hole in the center of the net. ---------- Forwarded message ---------- Subject: Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone From: Tim Goetze <tim(a)quitte.de> To: linux-audio-dev(a)music.columbia.edu Date: Mon, 28 Oct 2002 14:20:27 +0100 (CET) Steve Harris wrote: >On Mon, Oct 28, 2002 at 02:41:08 +0100, Tim Goetze wrote: >> http://quitte.de/easy.mp3 > >That sounds pretty good. The attack sounds a bit muted to me though, is >that deliberate or should it have more bite? it could do with a little more bite, yes. it's the neck pickup with the tone pot at the guitar closed slightly, that's the way i usually play the super 60. this way, it stress-tests our setup's capability of generating higher-order harmonics during attack. >> >Yeah, fix the rectifier. I had a quick look at it and it looks like I did >> >something fairly obvious (its basicly a compressor, but with a waveshaper >> >instead of a linear gain). >> >> the shaper code looks familiar. admit i'm hoping for a performance >> and quality gain. > >Yup, I adapted what I had around ;) I think something symmetric and harder >might be better though, I'l see what I can do. Maybe it should just be a >peak following compressor... my original though was that the power supply >sag would cause a distortion, but maybe it wont. whatever it does, it helps. ;) probably because it adds more distortion in the attack phase. so it may not do exactly what is intended on the smaller scale, but what is intended to be modeled overall. >I think the speed will go up dramatically when its bolted into one plugin. >I want to get the ordering right first though. OTOH there is still mic >effects to be added in :( speaking for my selfish self, i'm just glad i don't have to care about mic placement at all anymore. i'll be happy to create more iir 'convolvers' or extend 'unmatched' for more impulses though, as long as they can be made to converge. tim

22 years, 10 months

Re: [linux-audio-dev] Free Publicity - DJCJ Linux Audio Developers Tech Support Database.

by Patrick Shirkey

>> The aim of the images at the top is to provide one click access to >>the most popular sites for information about Linux audio. I really >>don't want to move them. They could do with being slightly smaller >>perhaps. >>I'd like to suggest that you put them in a table at the top or side of >>the page rather than a frame -- I don't think they need to stay >>visible if you scroll down or follow a link. Yes or I could give them their own page. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 10 months

Re: [linux-audio-dev] Free Publicity - DJCJ Linux Audio Developers Tech Support Database.

by Patrick Shirkey

>Web-design seems a bit off topic, but... I don't understand that. Everyone always bitches about the lack of documentation for Linux audio. This site has been designed to address that problem specifically from a new user POV. Getting it right should be very much on topic. Just because it isn't hosted on Sourceforge doesn't mean it's not open source. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 10 months

[linux-audio-dev] Re: [linux-audio-announce] DJCJ Linux Audio Developers Tech Support database.

by Patrick Shirkey

Conrad Parker wrote: > for example, we could provide some level of commercial support for Linux > audio stuff from CSIRO, but we could only focus on a small domain (MPEG > audio, vorbis, sweep, and custom engineering related to analysis) and can't > possibly list ourselves as providing general Linux audio tech support. > We're primarily a research agency and any external work we take on needs to > be somehow relevant to our projects. > > I'd imagine there'd be a large number of people who similarly wouldn't be > willing to list themselves for general tech support, due to only having > limited skills or interests, or simply for commercial reasons. > Conrad has made a good case for providing a column to list the skills, specialities of each supporter/company. Only I cannot decide on the best word to represent that. Any suggestions? -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 10 months

[linux-audio-dev] Ardour

by Lea Anthony

Does it have a built in Wave editor? I can't see anything in the features list or FAQ. -Lea.

22 years, 10 months

[linux-audio-dev] MWPP implementation guide ...

by John Lazzaro

Hi everyone, Just sent off the first draft of the "Implementation Guide" for MWPP, in time for the deadline for the next IETF meeting. You can download it as: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt See below for the abstract. A few sections in the main body, as well as the Appendices, remain to be written, but I decided to send it off because the completed parts are in pretty good shape, and early feedback on the direction the document is taking (as the non-normative companion to the main MWPP document) would be helpful. The current plan is to make some minor changes to the normative MWPP document, in response to comments received since its September 22 submission, and resubmit it in time for the meeting deadline for updated documents. So if you're holding onto any comments on this document, now is a good time to send them along -- this document can be downloaded as: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt --- INTERNET-DRAFT John Lazzaro October 27, 2002 John Wawrzynek Expires: April 27, 2003 UC Berkeley An Implementation Guide to the MIDI Wire Protocol Packetization (MWPP) <draft-lazzaro-avt-mwpp-coding-guidelines-00.txt> Abstract This memo offers non-normative implementation guidance for the MIDI Wire Protocol Packetization (MWPP), an RTP packetization for the MIDI command language. The memo provides a detailed description of a sample MWPP application: an interactive MIDI session between two parties that send and receive RTP and RTCP flows over unicast UDP transport. The Appendices focus on special issues that arise in other types of applications: content-streaming applications, multi- party applications, applications that use reliable transport such as TCP, applications that do not use RTCP, and applications that send several MWPP RTP streams in a single session. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 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