Hi Paul, Thanks to taking the initiative to get this rolling, here is my feedback on your items. As a general comment I think a lot of the problems with linux Sound and Video not 'just working' can found in the kernel layer with bad and inconsistently behaving drivers as one point. (Luckily we have a core kernel developer on this list who I am sure will rush in to fix anything pointed out from now on, just so that nobody will call him a FUCKING IDIOT who only cares about pandering journalists for free beef tartar and not about the needs of his users :)
Also as Greg pointed out, whatever we do here we need to take Video into account. A lot of the problems we discovered during the development of GStreamer (and now solved) is issues such as getting correct sync when recording from separate systems like a webcam for video and the soundcard for audio. >CONFIGURATION (see also MIXING below) > > - identify what audio h/w exists on the system > - identify what network audio destinations are available > - choose some given audio h/w or network endpoint > as the default for input > - ditto for output > - enable/disable given audio h/w > - easily (auto)load any kernel modules required for > given functionality Other suggested items include - * Proper handling of removeable/plugable multimedia hardware - GNOME bug entry about the problem in regards to soundcards - http://bugzilla.gnome.org/show_bug.cgi?id=172594 * Lessen need for probing - Probbing have two issues currently a) due to sucky drivers you can't always trust the response you are getting back and b) it takes time. Some sort of driver database storing capabilities is needed so that users don't have to sit around drumming their fingers while their multimedia software probes all their multimedia hardware , this is not just audio related, but a problem with things like webcams etc. also. The non-trustable results issue might of course come true with a driver database as it is with the actual drivers, but the time consumption issue should be resolvable. * Better handling of Surround Sound including SPDIF. A lot of soundcards report a IEC958, but don't really have any hardware connections for it. Another problem is that we don't really have a Surround Sound optimal sound format currently. > PLAYBACK > > * user driven (e.g. play(1)) > * app driven (e.g. {kde,gnome_play}_audiofile()) > - play a PCM encoded audio file (specifics as above) > - hear system sounds > - VOIP > - game audio > - music composition > - music editing > - video post production > Some extra items include - * handle tags * We should probably in general define a set of supported codecs/formats minimum. Xiph.org formats seems a natural choice as a starting point, with Dirac beeing added for video. Also for NLE's we should also maybe add MXF and maybe AAF in addition to Ogg as container formats. And of course a set of older stuff like for instance AIFF as mentioned elsewhere in this doc. > RECORDING > > - record from hardware inputs > * use default audio interface > * use other audio interface > * specify which h/w input to use > * control input gain > - record from other application(s) > - record from live (network-delivered) audio > streams > * PCM/lossless compression (WAV, FLAC etc) > * lossy compression (mp3, ogg etc) * If this is meant to be a free software audio requirements list then mp3 should be removed. It is not free. > MIXING > > - control h/w mixer device (if any) > > * allow use of a generic app for this > * NOTE to non-audio-focused readers: the h/w mixer > is part of the audio interface that is used > to control signal levels, input selection > for recording, and other h/w specific features. > Some pro-audio interfaces do not have a h/w mixer, > most consumer ones do. It has almost nothing > to do with "hardware mixing" which describes > the ability of the h/w to mix together multiple > software-delivered audio data streams. > > - multiple applications using soundcard simultaneously > - control application volumes independently > - provide necessary apps for controlling specialized > hardware (e.g. RME HDSP, ice1712, ice1724, liveFX) > ROUTING > > - route audio to specific h/w among several installed devices > - route audio between applications > - route audio across network > - route audio without using h/w (regardless to whether or > not h/w is available; e.g. streaming media) > MULTIUSER > > - which of the above should work in a multi-user scenario? > FORMATS > > - basically, the task list if covered by the above list, > but there are some added criteria: > > - audio data formats divide into: > - direct sample data (e.g. RIFF/WAV, AIFF) > - losslessly compressed (e.g. FLAC) > - lossy compression (e.g. Vorbis, MP3) > - apps that can handle a given division should all > handle the same set of formats, with equal prowess. > i.e. apps don't have to handle lossy compression > formats, but if they do, they should all handle > the same set of lossy compression formats. Principle: > minimize user suprise. > - user should see no or limited obstacles to handling > proprietary formats * Once again remove MP3 > MISC > > - use multiple soundcards as a single logical device > - use multiple sub-devices as a single logical device > (sub-devices are independent chipsets on > a single audio interface; many soundcards > have analog i/o and digital i/o available > as two different sub-devices) Another general comment is that such as list like these is both useful and useless. Its useful in the sense that it gives a general overview of what is wanted, but its useless in relation to implementation as it is way to lacking in details. Like a requirement to support Ogg without any details is something everyone could quickly checklist. Smooth handling of a chained Ogg consisting of a mix of audio-only and audio+video tracks and a variety of bitrates and codecs is a pain in the ass to get right :) Christian
_______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
