On Sat, Dec 17, 2005 at 03:51:37PM -0500, Lee Revell wrote: It's not the job of the browser to keep accounting on external apps. If it were, it'd be doomed to failure anyhow - that task can never be accomplished. Rather, it is up to the individual applications to do the right thing if there is a session already open. xmms has worked the way you seem to expect since its inception.

xmms has worked the way you seem to expect since its inception.

Because the Linux browsers are garbage. For some reason the people who develop them worry about bullshit like extensions and toolbars and making sure the apps are translated into Xhosa than fixing basic usability bugs like this.

I never heard of those sites so I checked it out. The first one I checked out worked great for me. It took a little time to load but it worked fine: http://bodyslam.ytmnd.com/

I never heard of those sites so I checked it out. The first one I checked out worked great for me. It took a little time to load but it worked fine: http://bodyslam.ytmnd.com/

least on my systems, which can end up with multiple mp3's playing at the same time. Stuff like starting an mp3/ogg/xxx file playing, and

( LAU folk: this is an initial outline of an email I want to dispatch to the desktop-architects list in the very near future. Your comments are eagerly sought. Note that this section specifically seeks to avoid any discussion of implementations or specific approachs. I would like to fully flesh out the list of tasks ASAP ) Making Sound Just Work ------------------------ One of the "second tier" of requirements mentioned several times at the OSDL Portland Linux Desktop Architects workshop was "making audio on Linux just work". Many people find it easy to leave this requirement lying around in various lists of goals and requirements, but before we can make any progress on defining a plan to implement the goal, we first need to define it rather more precisely. DEFINING THE GOAL ================= The list below is a set of tasks that a user could reasonably expect to perform on a computer running Linux that has access to zero, one or more audio interfaces. The desired task should either work, or produce a sensible and comprehensible error message explaining why it failed. For example, attempting to control input gain on a device that has no hardware mixer should explain that the device has no controls for input gain. PLAYBACK - play a compressed audio file * 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 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) compressed audio streams 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 MULTIUSER - which of the above should work in a multi-user scenario? MISC - use multiple soundcards as a single logical device