All times are UTC-06:00




Post new topic  Reply to topic  [ 17 posts ] 
Author Message
 Post subject: Improving Audio
PostPosted: Thu Oct 27, 2011 8:00 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi all,

To improve audio on the EfikaMX, try editing /etc/pulse/default.pa and where is says:
Code:
### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
add tsched=0 behind module-udev-detect, so that it looks like this:
Code:
### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect tsched=0
.else
After rebooting, this should eliminate any cracking/noise you might have experienced. Please reply in this thread if it makes a difference for you!


Johan

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
PostPosted: Fri Oct 28, 2011 3:09 pm 
Offline

Joined: Thu Jun 09, 2011 6:48 am
Posts: 13
Location: Waco, TX
Johan,

Why does this work? What does the setting do or change?

Thanks,

Bradley Norris


Top
   
 Post subject:
PostPosted: Fri Oct 28, 2011 4:17 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi Badley,

It turns off timer-based scheduling for PulseAudio and instead uses interrupt-driven scheduling. Timer-based scheduling should be better in theory, but can cause issues with some Alsa drivers. We believe that audio improves by adding this flag to go back to interrupt-driven scheduling.

Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
 Post subject:
PostPosted: Wed Nov 02, 2011 10:50 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Hi Badley,

It turns off timer-based scheduling for PulseAudio and instead uses interrupt-driven scheduling. Timer-based scheduling should be better in theory, but can cause issues with some Alsa drivers. We believe that audio improves by adding this flag to go back to interrupt-driven scheduling.

Johan.
The basic premise behind PulseAudio's scheduling is that by using high resolution timers PulseAudio can get to the buffer and put up new data before the audio chip is giving the system an emergency warning that the buffer is about to hit the end and needs new data. Some sound cards do this way too late to perform adequate click-free audio, and some sound cards (like streaming PA over a network) simply do not have a timely interrupt for lack of data (complicated by TCP/IP packet loss and so on) and the best way is to simply know when your buffer will last, start playing, and before it gets to the end or gives a late alarm, reschedule some new buffers to play audio.

Unfortunately either the high res timers available to PulseAudio or something to do with the scheduling latency of going into the kernel, modifying buffers and coming back takes far too long. Virtual Machines (in VirtualBox or VMWare workstation) tend to do better with interrupt based scheduling than timer based scheduling as the high resolution timers are emulated as a significantly lower resolution than the host system provides to a natively installed system.

Interrupts are a fact of life; they come through and they are serviced with a given latency and it in general does not matter if they are not handled within a certain period of time (although doing it exceptionally late is usually a problem, systems with 100 interrupt events potentially prioritized generally are built to withstand a little waiting).

Timers are in general not a fact of life. On x86 it is only very recently that they grew a high precision event timer (called the High Precision Event Timer, or HPET, introduced in about 2004/2005) which is required when you're doing fancy things like SMP where the CPU ("rdtsc" timestamp) counters get wildly out of sync, old PIT timer was hard to access (requires an io-mode read), had a limited number of schedulable events (3, but 2 of them are usually used by the system for other things) and in general pretty low resolution.

You can't guarantee that they are there, or even that they are synchronized or particularly real (many high resolution timers in Linux, especially with "tickless" systems, do not actually fire at the time they are ready to fire, only sometime way after when the system has decided it is not a detriment to power management or can batch timer events together).

My personal reading into this is that the timer used on Linux for the MX51 is too low resolution; it's a quit small counter and to stop it from overflowing too often the rate is quite slow, giving it a minimum time between events of somewhere around 3 milliseconds, with the average time to processing it and getting to the rest of the system between 4 and 7 milliseconds. In-kernel msleep(1) actually takes 4 or 5 ms (since it's not possible to count any other way you can't tell what it is, sometimes it's 4, sometimes it's 5, processing overhead included).

The average PulseAudio buffer size is 10ms which means that you will be lucky if you can send the buffer to the audio driver, and receive an event before it is too late to do anything about it.

Another fix for it is to go into /etc/pulse/daemon.conf and increase the default-fragment-size-msec value to 25 or 30 which will give the system much more time at the expense of possibly 15-20ms extra latency playing audio (this is not enough to notice in terms of expediency, but is definitely long enough for the human brain to notice the missing data, but PA does a good job of keeping buffers filled and chained).

_________________
Matt Sealey


Top
   
 Post subject: Pulse Audio and the MX51
PostPosted: Thu Nov 03, 2011 6:54 am 
Offline

Joined: Thu Jun 09, 2011 6:48 am
Posts: 13
Location: Waco, TX
Matt and Johan,

Thank you for the additional detail. I appreciate it because the Smartbook has become a useful resource (for the whole family) for playing streaming and mp3 music.

I am not an audiophile and have not done a side-by-side comparison, but have been impressed with the quality (excepting the ticks) of the signal... from Dubstep to Mandolin, it sounds quite nice. I have discovered the limits of the amplifier, but you'll hear no other complaints from me.

I will try the default-fragment-size-msec change. Its worth a short delay to ensure smooth playback.

I guess the followup question remains. What, if anything, changes with the MX53?


Top
   
PostPosted: Thu Nov 03, 2011 9:44 am 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi.
Quote:
What, if anything, changes with the MX53?
There is a different, low power audio codec on the MX53 system. Also, high definition video playback in 720p and 1080p is there. The extra clock speed makes the whole system feel more responsive.

All the software developments we've been doing over the past 6 months will be directly usable on the MX53. Quake 3 runs at 30fps, but that is without any optimization and with GLES 1.1. The driver we have there is operating close to the theoretical maximum performance.

More later...

Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
 Post subject:
PostPosted: Mon Nov 21, 2011 1:18 pm 
Offline

Joined: Thu Nov 10, 2011 10:24 am
Posts: 30
This change made a slight difference; however, there is still "ticking" (albeit less) during the playback from my "Amazon Cloudplayer" and mp3s downloaded from "Amazon".


Top
   
 Post subject:
PostPosted: Mon Nov 21, 2011 1:22 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi.

Is this on Netbook or Nettop? You might have to set the default sample rate for Pulse to 48000 on the Netbook and 44100 on the Nettop in /etc/pulse/daemon.conf.
Also, make sure the resample method is set to ffmpeg in the same file.


Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
 Post subject:
PostPosted: Mon Nov 21, 2011 1:49 pm 
Offline

Joined: Thu Nov 10, 2011 10:24 am
Posts: 30
I verified "default-sample-rate = 48000" and "resample-method = ffmpeg" are set correctly in /etc/pulse/daemon.conf

EfikaMX Smartbook

Still a little "crackle" from the online stream and downloaded files.


Top
   
 Post subject:
PostPosted: Tue Nov 22, 2011 5:22 pm 
Offline

Joined: Thu Nov 10, 2011 10:24 am
Posts: 30
The sound is particularly bad when running armhf!

Hints for improving?


Top
   
 Post subject:
PostPosted: Tue Nov 22, 2011 5:28 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi.

Could you check if the volume is not set to maximum? Pressing the F2 key once should make sure of this.

What kind of file (format, bit rate) etc. are you trying to play? Can you give a link?


Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
 Post subject:
PostPosted: Wed Nov 23, 2011 1:22 pm 
Offline

Joined: Thu Nov 10, 2011 10:24 am
Posts: 30
I've adjusted the volume up and down. The sound is "synthetic".

The same files play nicely (with a little snap, crackle, pop) using the Ubunutu Maverick instance on the local media.

Files are downloaded from the "Amazon MP3 Store".


Top
   
 Post subject:
PostPosted: Wed Nov 23, 2011 3:34 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi.

Just bought some music there to try and replicate your issue, but I can't. Have you tried listening with headphones? Did it change anything?

For the record, I only tested music played from the local media. I listened through some Metallica since it has some nice loud guitars and base.


Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet


Top
   
 Post subject: Improving Audio
PostPosted: Thu Nov 24, 2011 10:05 am 
Offline

Joined: Fri Nov 11, 2011 10:21 am
Posts: 21
Location: Netherlands
Hallo Johan,

The crackling is completely gone, when playing a CD or listening to internet radio (@128kbps), also under high CPU load, previously that caused quite a bit of crackling. What remains are occasional hickups, under high load, with Rhythmbox on maverick, Audacious on Debian armhf does not appear to suffer from this (I may need to try harder).

Frank.


Last edited by frankm on Fri Dec 09, 2011 6:05 am, edited 1 time in total.

Top
   
 Post subject:
PostPosted: Thu Dec 08, 2011 3:41 pm 
Offline

Joined: Thu Nov 10, 2011 10:24 am
Posts: 30
What is the best application for MP3 playback using Debian armhf?

I've tried rhythmbox but the quality is still way off.

Thanks!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 17 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group