Re: Another idea

> sound://0:mp3decode:http://www.some_domain.foo/some_mp3_file.mp3
> tcp://1234:disks://a2

What about progress?
I really enjoy watching the progress bar of wget sometimes..
Because I can see filesize/progress/ETA at one glance..
Would enhance piping solve this issue? I can think of also getting the
amount of piped data when opening a pipe as byte count or "not known"
value.. Then you might just do
> sound://0:mp3decode:pipemeter:http://www.some_domain.foo/some_mp3_file.mp3
pipemeter: progress 10 bytes out of 100 (10%) speed: 1 bytes per second

with pipemeter outputting transfer speed/ overall progress at this point?
But the display would get cluttered if mp3decode wants to display
progress, too.. I love to change play speed in mplayer .. So I would
like to have a commandline like this:
> sound://0:adjustplayspeed:mp3decode:pipemeter:http://www.some_domain.foo/some_mp3_file.mp3
But then there is problem:
> sound://0:adjustvolume:adjustplayspeed:mp3decode:[...]
Which program adjustvolume or adjustplayspeed should receive keyboard
input?

And of cause you need would need some additional abstraction layer..
Because I think there are some people listening to mp3 and also talking
(accoustically) to other peoples using some messenger..
Both programs using sound://0 would become a mess..

What do you think?

Marc