From kde-multimedia Sun Jun 10 16:48:35 2001 From: Stefan Westerfeld Date: Sun, 10 Jun 2001 16:48:35 +0000 To: kde-multimedia Subject: Re: Recording PCM audio with aRts X-MARC-Message: https://marc.info/?l=kde-multimedia&m=99219185520948 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--sdtB3X0nJg68CQEu" --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Hi! On Sun, Jun 10, 2001 at 03:04:49PM +0100, Rik Hemsley wrote: > #if Stefan Westerfeld > > > aRts currently uses no explicit selection of input sources, neither > > for midi nor for audio. Rather the current strategy is through the > > (Audio|Midi)Manager objects. This works like that: > > > > 1. you start recording (playing), describing what you do > > > > 2. there are predefined points where you can record data from (play > > data to),which the user can connect your application to through > > artscontrol > > > > 3. the next time your application records (plays) again, it will be > > connected to the same point again > > > > It might be that you might want to change something in there, but > > thats the way it works right now. > > This sounds to me like you're saying it's impossible to select an input > source with the aRts API and that the user would have to run artscontrol > to choose an input, right ? This isn't very nice for the user, as they > would probably prefer to just start the audio recording program, pick > an input (mic/line-in/cd/whatever) and press record. I agree. There are two different things here: 1. there will be more than one point within the aRts flowsystem from where you might want to record (i.e. you might want to record just the output that quake is playing to artsd, but not the mp3, or the soundcard input, or ...) 2. there will be more than one mixer selection for recording - i.e. cd, mic, line-in, ... Whereas choosing 1. is possible by using the aRts API (by using an appropriate Synth_BUS_DOWNLINK), choosing 2. is not. Esd for instance also doesn't allow you to choose 2., and the OSS programming guide recommends not to add subsets of mixer functionality to pcm style apps, but instead recording from whatever the user selected using the mixer. Nevertheless I agree with you that for the user it would be more convenient to select it in the recording application, just as for the user it would be more convenient if kmix and artscontrol would not be two seperate apps. Currently, artsd does know nothing about the hardware mixer. The KDE2.2 multimedia meeting summary says about mixers: ============================================================================= 4. Mixer issues ============================================================================= There was quite some discussion about mixers. The facts until now are: 1. kmix is about the hardware mixer only 2. aRts doesn't know anything about hardware mixers at all 3. artscontrol controls only what artsd does, which is among other things, controlling the output effect stack, midi instruments and so on 4. it might be nice to have aRts simulate a multichannel software mixer with effects 1. Stefan Schimanski is working on giving kmix pluggable architecture, that will work on the base of the Qt object model and dynamic loading, so it might be possible to easily plug aRts into kmix. A "one mixer for everything" approach might be more useful from a user-point-of-view than the current split. 2. Still, the general problem might be that aRts itself has no real "abstraction" for mixers in the IDL. There is the audiomanager thing that assumes the following: * there are apps that dynamically come and go * there are destinations (in form of busses) where audio might get played or recorded * you can assign apps to destinations On the other hand, one possible kmix model for apps would be dynamically appearing channels per app, i.e. a new quake channel would pop up once you start quake (whereas the current aRts idea would be more like: there are eight static audio outputs, audio01 .. audio08, and once you start quake, you can assign it to one of these channels). It might be nice to add an IDL based abstraction for "mixers", which will work the same for hardware and software mixers. This would provide things like network transparent (and language independant) mixer control. Maybe it would also make a good addition to the "AudioManager" style mixer interface we have now. This abstraction would also make it possible to have different clients access the mixer abstraction in a unified way. I.e. a Gtk frontend to the mixer would use the same software/hardware mixer than the KDE frontend. Turning the volume in the KDE frontend would make the sliders move int he Gtk frontend as well. 3. Entierly getting rid of artscontrol might not be the way to go, as there are midi related tasks in artscontrol which really don't belong into a mixer. But somehow unifying mixing would be "user-friendlier" than what we currently have. 4. aRts model is powerful enough to provide a multichannel, effect based mixer as software (and thats little code), and it might be possible to add that to artscontrol. Assignment of programs to channels is trivial. You can have equalizers (Synth_STD_EQUALIZER), per-channel-effects and so on. It will work on all applications. It should be implementable with not too much work (less than 1000 LOC). Whatever, this is a bit of a are research topic ;), and different things need to be done. Stefan Schimanski is working on the kmix plugin architecture (1). Stefan Gehn wanted to have a look at the GUI side of building a mixer (4). I can help with getting the necessary backend work done for (4). ============================================================================= > > * opening, reading, closing: > > > > Well, recording is still somewhat on the aRts TODO list, but here is an > > overview what works and what does not. > > > > A. recording with server-side objects > > > > Creating a Synth_AMAN_RECORD (which does that AudioManager thing), and > > connecting it to a Synth_CAPTURE_WAV is the simplest style of > > recording. It will create a wave file in /tmp/mcop-/... - I > > did hardcode that for now because of security considerations (what if > > you get an .arts file by mail that "records" some file which already > > exists and thus overwrites it? or creates a file which you - as > > stupid user - will never find again?). > > You say you hardcoded the location that is saved to - so how would I go > about working around this ? Saving in /tmp isn't very useful. My /tmp > is in RAM :) Well, I think you can add a method to Synth_CAPTURE_WAV void setFilename(string filename); that would be ok. In the end, you will maybe find out that you want to have your own implementation of Synth_CAPTURE_WAV anyway (it's really simple code) to allow 8bit recording, or mono recording or something like that, if that is so, you can simply copy it, and make a derived one. I don't want to add a filename attribute due do security implications. > Also, I'll want to monitor the input with level meters, so > the user can see that their input is working. If the data is going > directly to a file behind my back, I won't be able to do that. Well, monitoring the input is easy. Simply instead of doing Synth_AMAN_RECORD (or Synth_BUS_DOWNLINK) | | V V Synth_CAPTURE_WAV do Synth_AMAN_RECORD (or Synth_BUS_DOWNLINK) | | V V SomeVolumeMeter (for instance StereoVolumeControl, which is also used by | | artscontrol) V V Synth_CAPTURE_WAV > > So... as conclusion I'd say, it would be great if you write that simple > > recording application (we really really need that), and fix things on > > the way. (/me currently always uses artsbuilder with .arts files to do > > recording, which is probably not the ideal thing). > > Sorry, I don't want to spend a lot of time learning about aRts internals > and fixing stuff, I just want to write very simple audio recording app. > > If aRts doesn't support recording properly yet, that's ok, I'll just > drop the idea. Well, I hope I have explained properly what there is to know about aRts and recording. It's up to you what do to with that knowledge. I would be really really happy to see a simple recording app, and if it is limited through aRts in what it can do right now, it will be still better than no recording app at all. Btw, I am attaching the .arts file so you can see what I was talking about. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="capture_to_wav.arts" name=capture_to_wav module=Arts::Synth_MUL { id=4 x=3 y=2 port=invalue1 { id=5 connect_to=22 } port=invalue2 { id=6 audio_data=0.14000 } port=outvalue { id=7 connect_to=28 } } module=Arts::Synth_MUL { id=12 x=6 y=2 port=invalue1 { id=13 connect_to=23 } port=invalue2 { id=14 audio_data=0.14000 } port=outvalue { id=15 connect_to=29 } } module=Arts::Synth_BUS_DOWNLINK { id=20 x=4 y=0 port=busname { id=21 string_data=out_soundcard } port=left { id=22 connect_to=5 } port=right { id=23 connect_to=13 } } module=Arts::Synth_CAPTURE_WAV { id=27 x=5 y=4 port=left { id=28 connect_to=7 } port=right { id=29 connect_to=15 } } --sdtB3X0nJg68CQEu-- _______________________________________________ Kde-multimedia mailing list Kde-multimedia@master.kde.org http://master.kde.org/mailman/listinfo/kde-multimedia