Ticket #11334 (new defect)

Opened 3 years ago

Last modified 3 years ago

XO-1.75 audio sounds terrible in some configurations

Reported by: dsd Owned by: saadia
Priority: normal Milestone: 1.75-software
Component: kernel Version: Development source as of this date
Keywords: Cc: corbet@…
Action Needed: design Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Mitch suggested " the codec does not have digital antialiasing, so, while it can play at numerous rates, anything lower than 48000 will be subject to "stairstepping", which results in analog domain aliasing that sounds awful"

However, after we made that change, so that the driver would only offer 48k and so that alsa-lib would be forced to resample anything that came in at other rates, we found that sounds (like those which come in Scratch) now sound bad. They are 11025Hz, and sound fine if sent to the hardware like that, but sound terrible when resampled by ALSA.

With a kernel that advertises the full set of rates, the horrible audio (which is presumably the analog domain aliasing referred to by mitch) can be reproduced with:

gst-launch audiotestsrc ! audio/x-raw-int,rate=44100,channels=1

but interestingly, if you run it with 2 channels, it sounds fine. I confirmed that the parameters being sent to the hardware do not differ in anything but the obvious in these 2 cases - with 2 channels a larger buffer is used, and it is configured as 2 channels, but the rest is fine.

I've experimented with the full range of rate and channels values, results are:

Ratechannels=1channels=2
8000OKOK
11025OKOK
16000OKOK
22050BADOK
32000OKOK
44100BADOK
48000OKOK
64000OKBAD
88200WRONG TONEBAD
96000OKBAD
176400BADBAD
192000BADBAD

"BAD" means that the sound was crackly. "WRONG TONE" means that the sound was not crackly but the test produced a different audible tone from the norm.

Attachments

Change History

Changed 3 years ago by dsd

One option, at least for the short term, is to restrict the offered rates to those that have "OK" in both columns above. They are:

		.rate_min	= 8000,
		.rate_max	= 48000,
		.rates		= SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |
				  SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_32000 |
				  SNDRV_PCM_RATE_48000,

In this configuration, I can run the above testing matrix with only one bad sound produced: 22050Hz (which is downsampled to 16000 by alsa) with 1 channel has some blips (2 channels is fine).

Changed 3 years ago by dsd

Testing with speaker-test producing a sine wave, I cannot reproduce any crackles at any sample rate. Mitch suggests that there could be something wrong with the buffer management - we arent recycling buffers fast enough upon interrupts, or something like that. The difference in results could also be due to the use of buffer sizes that match badly with the audio DMA buffer size.

Changed 3 years ago by erikos

Command should be: gst-launch audiotestsrc ! audio/x-raw-int,rate=44100,channels=1 ! alsasink

Changed 3 years ago by erikos

Playing the above command back on build 883 with latest kernel (kernel-3.0.0_xo1.75-20111107.1918.olpc.4fbb7db.armv7l.rpm) does produce a choppy sound and only the left speaker is driven.

Changed 3 years ago by martin.langhoff

  • milestone changed from 11.3.0 to 1.75-software

Keeping this one on the 1.75-software milestone, which we're using to triage low-level stuff.

Changed 3 years ago by martin.langhoff

Changed 3 years ago by martin.langhoff

With Jon's ASOC-mmp2-pcm-Limit-period-size-to-half-the-buffer-s patch, I run

gst-launch audiotestsrc ! audio/x-raw-int,rate=44100,channels=1 ! alsasink

(Note the alsasink. I assume that the original instructions forgot to include it...)

Rate channels=1 channels=2
8000 OK OK
11025 OK OK
16000 OK OK
22050 BAD OK
32000 OK OK
44100 BAD OK
48000 OK OK
64000 OK OK
88200 OK OK
96000 OK OK
176400 ERROR ERROR
192000 ERROR ERROR

Where ERROR looks like:

[olpc@xo-6d-81-67 ~]$ gst-launch  audiotestsrc ! audio/x-raw-int,rate=176400,channels=1 ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: Could not get/set settings from/on resource.
Additional debug info:
gstalsasink.c(531): set_hwparams (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:
Unable to set hw params for playback: Invalid argument
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

At some sampling rates we get a bit of crackling for the first second or so.

Changed 3 years ago by saadia

Instead of just supporting 48000 as a playback rate, we are now listing 8000, 11025, 16000, 22050, 32000 and 48000. The results are still as shown above, with the choppy sound at 22050 and 44100. The Activity that this affects most evidently is "Speak" which is 1 channel at 22050.

Changed 3 years ago by saadia

  • next_action changed from never set to test in build

I have changed the channels_min value for playback to be 2. Now mono sounds come out of both speakers. Playback at 44100 and 22050 sounds good. Please recheck with the attached patch.

Changed 3 years ago by saadia

  • owner changed from saadia to Quozl

Changed 3 years ago by Quozl

  • owner changed from Quozl to saadia
  • next_action changed from test in build to design
  • version changed from not specified to Development source as of this date

Tested in kernel e3f598e, with volume set one step down from maximum due to the distortion reported in my comment to #11422. Results:

  • regardless of channel=1 or channel=2, the output is driven to both speakers, and they sound equal,
  • at sample rate of 8000, and to a lesser extent at 11025, an aliasing or stepping tone is overlaid over the test tone, which on an oscilloscope shows as a stepped sine wave,
  • at sample rates of 16000 and higher, an aliasing tone is not easily heard, but is present according to the oscilloscope, and will be audible to children,
  • at a sample rate of 44100, then from 64000 to 192000, there is a gradual increase in random interruptions apparently caused by system activity, and especially wireless network activity.
Ratechannels=1
8000ok aa
11025ok a
16000ok
22050ok
32000ok
44100ok n
48000ok
64000ok n
88200ok inn
96000ok iinn
176400ok iiin
192000ok iiiin

Letter key:

  • a = aliasing tone heard,
  • n = predicted network activity (ssh keystrokes) triggered interrupts to sound,
  • i = unpredictable interruptions were heard.

It is important that the aliasing is avoided, or at least tested by a child, by preference one with musical experience. Adults can't easily assess the impact of this effect. Connecting an oscilloscope to the headphone output is one way to check for the presence of aliasing.

These results show that the hardware is being driven at incorrect sample rates. I recommend that the resampling be done in software, with the hardware driven at 48000.

Changed 3 years ago by saadia

  • cc corbet@… added
Note: See TracTickets for help on using tickets.