Re: Ogg vorbis performance.
Troy Benjegerdes wrote: It should have essentially zero overhead when properly configured, and when its not doing anything fancy. I don't think these performance problems are fundamental. Don't think, benchmark :) There are a ton of non-obvious reasons one approach might seem just fine but really suck. (cache alignments, tlb misses, ctx switch overhead) One step ahead of you. Thats how I found out about the floating point resampling... The reason I think that the performance overhead will be negligible is that it should be using shared memory to pass the data around, and it should never actually copy / touch the audio data inside of pulseaudio unless it hits a hardware / alsa limitation. We can crank up the buffer size (and latency) if things like context switches cause trouble... At any rate, we can't measure anything until we get rid of the floating point resampling... For power and performance reasons on a cell phone, I think anything a sound server does would be much better done in the kernel-level ALSA drivers. The only downside I can see to this approach whether the in-kernel bluetooth audio drivers are any good. Kernel-level software resampling should be just as expensive as userspace resampling... Pulseaudio does seem to do some soft-realtime stuff and adds a bit of device transparency. Last I tried bluetooth-audio on my laptop I had to run a userspace daemon. I have no idea what would happen with Alsa if you tried to transfer a call between the speaker and the bluetooth set. I think pulseaudio can handle this sort of thing correctly. All my whining aside, seamless speaker->bluetooth handoff seems to be a 'must-have' feature. Although I would like to hear a good reason why the kernel shouldn't be in charge of that. Well, it's kind of a user space thing, since they're two different (unrelated) devices. Also, pulseaudio can hand off audio over the network, and supports some sophisticated audio processing stuff that probably shouldn't live in the kernel... On the other hand, for all I know, ALSA or some simple hack may be able to handle the bluetooth thing... Speaking of which.. do we have any way to measure the power consumption of playing a reference .ogg file without special hardware? Are the built-in battery charge management counters good enough? Good question. :) Also, pulseaudio may be preventing the sound card and cpu from falling asleep, even when no sounds are being played. From what I can tell, it's been configured to never go idle.
Re: Ogg vorbis performance.
> It should have essentially zero overhead when properly configured, and > when its not doing anything fancy. I don't think these performance > problems are fundamental. Don't think, benchmark :) There are a ton of non-obvious reasons one approach might seem just fine but really suck. (cache alignments, tlb misses, ctx switch overhead) > > > > >For power and performance reasons on a cell phone, I think anything a > >sound server does would be much better done in the kernel-level ALSA > >drivers. The only downside I can see to this approach whether the > >in-kernel bluetooth audio drivers are any good. > > > > Kernel-level software resampling should be just as expensive as > userspace resampling... Pulseaudio does seem to do some soft-realtime > stuff and adds a bit of device transparency. > > >Last I tried bluetooth-audio on my laptop I had to run a userspace > >daemon. > > I have no idea what would happen with Alsa if you tried to transfer a > call between the speaker and the bluetooth set. I think pulseaudio can > handle this sort of thing correctly. All my whining aside, seamless speaker->bluetooth handoff seems to be a 'must-have' feature. Although I would like to hear a good reason why the kernel shouldn't be in charge of that. > > > >Speaking of which.. do we have any way to measure the power consumption > >of playing a reference .ogg file without special hardware? Are the > >built-in battery charge management counters good enough? > > > > Good question. :) Also, pulseaudio may be preventing the sound card and > cpu from falling asleep, even when no sounds are being played. From > what I can tell, it's been configured to never go idle.
Re: Ogg vorbis performance.
Troy Benjegerdes wrote: On Thu, Jul 17, 2008 at 05:46:17PM +0200, Alexey Feldgendler wrote: On Thu, 17 Jul 2008 17:27:37 +0200, Russell Sears <[EMAIL PROTECTED]> wrote: I uploaded a fix to the bug tracker. It bypasses PulseAudio and uses ALSA. Any idea why that helps? In principle, ALSA and PulseAudio should have to perform the same computations to play the sound back (alsa contains a software resampler...) I haven't been able to find any obviously mistakes in the configuration files. Also, are there any bad implications to bypassing pulseaudio? I haven't noticed any. I'd like to get ogg vorbis (and anything else that outputs 16bit/44.1kHz) fixed in the official image... And why again do we need pulseaudio at all? It does some nice things, like multi-channel mixing, network transparency, synchronization of multiple audio devices. (though gstreamer and alsa do some of these things as well...) It should have essentially zero overhead when properly configured, and when its not doing anything fancy. I don't think these performance problems are fundamental. For power and performance reasons on a cell phone, I think anything a sound server does would be much better done in the kernel-level ALSA drivers. The only downside I can see to this approach whether the in-kernel bluetooth audio drivers are any good. Kernel-level software resampling should be just as expensive as userspace resampling... Pulseaudio does seem to do some soft-realtime stuff and adds a bit of device transparency. Last I tried bluetooth-audio on my laptop I had to run a userspace daemon. I have no idea what would happen with Alsa if you tried to transfer a call between the speaker and the bluetooth set. I think pulseaudio can handle this sort of thing correctly. Speaking of which.. do we have any way to measure the power consumption of playing a reference .ogg file without special hardware? Are the built-in battery charge management counters good enough? Good question. :) Also, pulseaudio may be preventing the sound card and cpu from falling asleep, even when no sounds are being played. From what I can tell, it's been configured to never go idle. -Rusty
Re: Ogg vorbis performance.
On Thu, Jul 17, 2008 at 05:46:17PM +0200, Alexey Feldgendler wrote: > On Thu, 17 Jul 2008 17:27:37 +0200, Russell Sears <[EMAIL PROTECTED]> > wrote: > > >I uploaded a fix to the bug tracker. It bypasses PulseAudio and uses > >ALSA. Any idea why that helps? In principle, ALSA and PulseAudio > >should have to perform the same computations to play the sound back > >(alsa contains a software resampler...) I haven't been able to find any > >obviously mistakes in the configuration files. > > > >Also, are there any bad implications to bypassing pulseaudio? I haven't > >noticed any. I'd like to get ogg vorbis (and anything else that outputs > >16bit/44.1kHz) fixed in the official image... > > And why again do we need pulseaudio at all? For power and performance reasons on a cell phone, I think anything a sound server does would be much better done in the kernel-level ALSA drivers. The only downside I can see to this approach whether the in-kernel bluetooth audio drivers are any good. Last I tried bluetooth-audio on my laptop I had to run a userspace daemon. Speaking of which.. do we have any way to measure the power consumption of playing a reference .ogg file without special hardware? Are the built-in battery charge management counters good enough?
Re: Ogg vorbis performance.
On Thu, 17 Jul 2008 17:27:37 +0200, Russell Sears <[EMAIL PROTECTED]> wrote: I uploaded a fix to the bug tracker. It bypasses PulseAudio and uses ALSA. Any idea why that helps? In principle, ALSA and PulseAudio should have to perform the same computations to play the sound back (alsa contains a software resampler...) I haven't been able to find any obviously mistakes in the configuration files. Also, are there any bad implications to bypassing pulseaudio? I haven't noticed any. I'd like to get ogg vorbis (and anything else that outputs 16bit/44.1kHz) fixed in the official image... And why again do we need pulseaudio at all? -- Alexey Feldgendler <[EMAIL PROTECTED]> [ICQ: 115226275] http://feldgendler.livejournal.com
Re: Ogg vorbis performance.
Russell Sears wrote: Flemming Richter Mikkelsen wrote: On 2008-07-13, Russell Sears <[EMAIL PROTECTED]> wrote: Sören Apel wrote: Heya, On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote: I've noticed that my freerunner is *almost* fast enough to play my ogg vorbis files; running a second app, or even gpsd causes the media player to skip, then to go silent. Yep. What's been done to get ogg vorbis to perform well so far? ogg123, oggdec seem to be able to decode in roughly 2/3's realtime, which is similar to the CPU usage of openmoko-mediaplayer. If I remember correctly it was a problem with the sample rate/sample format, meaning that resampling had to take place - which eats CPU like candy. Ouch. What sample rate does the hardware provide, and does pulseaudio or gstreamer do the resampling? Also, decoding to /dev/null is slow... That shouldn't resample should it? I've noticed that things I've encoded more recently seem to be less likely to play (perhaps I changed an encoding setting at some point...), but that it varies from track to track... I'll time some files, and see if I can find a pattern. Thanks! -Rusty I noticed that gstreamer is using libvorbisi (tremor) since there is no floating point unit. It looks like there are three ways to make it go faster: - Tremolo, which is ARM specific, and claims 15-20% better performance - _LOW_ACCURACY_ mode - The "low-mem" branch of tremor Which of these have been tried so far? None, as I didn't find the time unfortunately. You're more than welcome to try these :) I use my Freerunner as a mediaplayer. I installed mplayer and stored my ogg vorbis files on the micro SD card. They are encoded with high, but floating bitrate. I got no problems when playing. Also, please note that ogg vorbis is extremely flexible and you can select any bitrate for playback without the need for reencode. There is now a bug for this, number 1614. I'm beginning to agree with Sören; I think it's resampling or doing software mixing in the pulseaudio layer. Getting pulseaudio to perform passthrough will probably help. Also, I'm attempting to build all the packages from scratch, and figure out who links to which vorbis decoder, and with which compilation options. Hopefully, we can save some cycles there too. -Rusty I uploaded a fix to the bug tracker. It bypasses PulseAudio and uses ALSA. Any idea why that helps? In principle, ALSA and PulseAudio should have to perform the same computations to play the sound back (alsa contains a software resampler...) I haven't been able to find any obviously mistakes in the configuration files. Also, are there any bad implications to bypassing pulseaudio? I haven't noticed any. I'd like to get ogg vorbis (and anything else that outputs 16bit/44.1kHz) fixed in the official image... -Rusty
Re: Ogg vorbis performance.
Flemming Richter Mikkelsen wrote: On 2008-07-13, Russell Sears <[EMAIL PROTECTED]> wrote: Sören Apel wrote: Heya, On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote: I've noticed that my freerunner is *almost* fast enough to play my ogg vorbis files; running a second app, or even gpsd causes the media player to skip, then to go silent. Yep. What's been done to get ogg vorbis to perform well so far? ogg123, oggdec seem to be able to decode in roughly 2/3's realtime, which is similar to the CPU usage of openmoko-mediaplayer. If I remember correctly it was a problem with the sample rate/sample format, meaning that resampling had to take place - which eats CPU like candy. Ouch. What sample rate does the hardware provide, and does pulseaudio or gstreamer do the resampling? Also, decoding to /dev/null is slow... That shouldn't resample should it? I've noticed that things I've encoded more recently seem to be less likely to play (perhaps I changed an encoding setting at some point...), but that it varies from track to track... I'll time some files, and see if I can find a pattern. Thanks! -Rusty I noticed that gstreamer is using libvorbisi (tremor) since there is no floating point unit. It looks like there are three ways to make it go faster: - Tremolo, which is ARM specific, and claims 15-20% better performance - _LOW_ACCURACY_ mode - The "low-mem" branch of tremor Which of these have been tried so far? None, as I didn't find the time unfortunately. You're more than welcome to try these :) I use my Freerunner as a mediaplayer. I installed mplayer and stored my ogg vorbis files on the micro SD card. They are encoded with high, but floating bitrate. I got no problems when playing. Also, please note that ogg vorbis is extremely flexible and you can select any bitrate for playback without the need for reencode. There is now a bug for this, number 1614. I'm beginning to agree with Sören; I think it's resampling or doing software mixing in the pulseaudio layer. Getting pulseaudio to perform passthrough will probably help. Also, I'm attempting to build all the packages from scratch, and figure out who links to which vorbis decoder, and with which compilation options. Hopefully, we can save some cycles there too. -Rusty
Re: Ogg vorbis performance.
On 2008-07-13, Russell Sears <[EMAIL PROTECTED]> wrote: > Sören Apel wrote: > > Heya, > > > > On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote: > > > > > I've noticed that my freerunner is *almost* fast enough to play my ogg > vorbis files; running a second app, or even gpsd causes the media player to > skip, then to go silent. > > > > > > > Yep. > > > > > > > What's been done to get ogg vorbis to perform well so far? ogg123, > oggdec seem to be able to decode in roughly 2/3's realtime, which is similar > to the CPU usage of openmoko-mediaplayer. > > > > > > > If I remember correctly it was a problem with the sample rate/sample > > format, > > meaning that resampling had to take place - which eats CPU like candy. > > > > Ouch. What sample rate does the hardware provide, and does pulseaudio or > gstreamer do the resampling? Also, decoding to /dev/null is slow... That > shouldn't resample should it? > > I've noticed that things I've encoded more recently seem to be less likely > to play (perhaps I changed an encoding setting at some point...), but that > it varies from track to track... I'll time some files, and see if I can > find a pattern. > > Thanks! > > -Rusty > > > > > > > > > I noticed that gstreamer is using libvorbisi (tremor) since there is no > floating point unit. It looks like there are three ways to make it go > faster: > > > > > > - Tremolo, which is ARM specific, and claims 15-20% better performance > > > - _LOW_ACCURACY_ mode > > > - The "low-mem" branch of tremor > > > > > > Which of these have been tried so far? > > > > > > > None, as I didn't find the time unfortunately. You're more than welcome to > try these :) I use my Freerunner as a mediaplayer. I installed mplayer and stored my ogg vorbis files on the micro SD card. They are encoded with high, but floating bitrate. I got no problems when playing. Also, please note that ogg vorbis is extremely flexible and you can select any bitrate for playback without the need for reencode.
Re: Ogg vorbis performance.
Sören Apel wrote: Heya, On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote: I've noticed that my freerunner is *almost* fast enough to play my ogg vorbis files; running a second app, or even gpsd causes the media player to skip, then to go silent. Yep. What's been done to get ogg vorbis to perform well so far? ogg123, oggdec seem to be able to decode in roughly 2/3's realtime, which is similar to the CPU usage of openmoko-mediaplayer. If I remember correctly it was a problem with the sample rate/sample format, meaning that resampling had to take place - which eats CPU like candy. Ouch. What sample rate does the hardware provide, and does pulseaudio or gstreamer do the resampling? Also, decoding to /dev/null is slow... That shouldn't resample should it? I've noticed that things I've encoded more recently seem to be less likely to play (perhaps I changed an encoding setting at some point...), but that it varies from track to track... I'll time some files, and see if I can find a pattern. Thanks! -Rusty I noticed that gstreamer is using libvorbisi (tremor) since there is no floating point unit. It looks like there are three ways to make it go faster: - Tremolo, which is ARM specific, and claims 15-20% better performance - _LOW_ACCURACY_ mode - The "low-mem" branch of tremor Which of these have been tried so far? None, as I didn't find the time unfortunately. You're more than welcome to try these :) -Soeren
Re: Ogg vorbis performance.
Heya, On Sat, 2008-07-12 at 14:27 -0700, Russell Sears wrote: > I've noticed that my freerunner is *almost* fast enough to play my ogg > vorbis files; running a second app, or even gpsd causes the media player > to skip, then to go silent. Yep. > What's been done to get ogg vorbis to perform well so far? ogg123, > oggdec seem to be able to decode in roughly 2/3's realtime, which is > similar to the CPU usage of openmoko-mediaplayer. If I remember correctly it was a problem with the sample rate/sample format, meaning that resampling had to take place - which eats CPU like candy. > I noticed that gstreamer is using libvorbisi (tremor) since there is no > floating point unit. It looks like there are three ways to make it go > faster: > > - Tremolo, which is ARM specific, and claims 15-20% better performance > - _LOW_ACCURACY_ mode > - The "low-mem" branch of tremor > > Which of these have been tried so far? None, as I didn't find the time unfortunately. You're more than welcome to try these :) -Soeren signature.asc Description: This is a digitally signed message part
Ogg vorbis performance.
I've noticed that my freerunner is *almost* fast enough to play my ogg vorbis files; running a second app, or even gpsd causes the media player to skip, then to go silent. What's been done to get ogg vorbis to perform well so far? ogg123, oggdec seem to be able to decode in roughly 2/3's realtime, which is similar to the CPU usage of openmoko-mediaplayer. I noticed that gstreamer is using libvorbisi (tremor) since there is no floating point unit. It looks like there are three ways to make it go faster: - Tremolo, which is ARM specific, and claims 15-20% better performance - _LOW_ACCURACY_ mode - The "low-mem" branch of tremor Which of these have been tried so far? Thanks, Rusty
