mmap to snd-mmp2-pcm fails

[erikos]

All the gstreamer related tests did fail in os8: http://wiki.laptop.org/go/User:Erikos/11.3.0/Audio/test_os8

simple gst-launch test:

$ gst-launch audiotestsrc ! audioconvert ! audioresample ! 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: No such device or address
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Error in Record:

1317633789.352501 ERROR record:aplay.py: play_pipe: Could not get/set settings from/on resource. gstalsasink.c(531): set_hwparams (): /GstPlayBin:playbin0/GstBin:abin/GstAutoAudioSink:audiosink/GstAlsaSink:audiosink-actual-sink-alsa:
Unable to set hw params for playback: No such device or address

Error in Browse/Totem:

TotemEmbedded-Message: Viewer state: PLAYING
** (sugar-activity:1775): DEBUG: OpenURI reply
** (sugar-activity:1775): DEBUG: 0x1092908: "Command 'Play'"
TotemEmbedded-Message: totem_embedded_do_command: Play
** Message: Error: Could not get/set settings from/on resource.
gstalsasink.c(531): set_hwparams (): /GstPlayBin2:play/GstPlaySink:playsink0/GstBin:abin/GstBin:audiosinkbin/GstGConfAudioSink:audio-sink/GstBin:bin2/GstAutoAudioSink:autoaudiosink1/GstAlsaSink:autoaudiosink1-actual-sink-alsa:
Unable to set hw params for playback: No such device or address

TotemEmbedded-Message: Viewer state: STOPPED
TotemEmbedded-Message: totem_embedded_set_error: 'Could not get/set settings from/on resource.'
TotemEmbedded-Message: totem_embedded_set_error_logo called by browser plugin

Blaming #10831 for now.

[erikos]

logs with GST_DEBUG=2

[erikos]

logs with GST_DEBUG=3 and GST_DEBUG_NO_COLOR=1

[dsd]

ok, looks like an issue in alsa-lib (not gstreamer). might be worthwhile trying some alsa-lib sample apps or tests if there are any.

[dsd]

All of these cases trigger a codepath where the area of physical memory used for DMA communication with the device is mapped into userspace. The mmp2_pcm_mmap() function is broken here.

The reason audio works elsewhere is that, for some reason, other codepaths do not use this direct memory access for audio recording/playback. I presume there is a good reason for this. Either way, it is good that the mmap codepath is being used at least in some cases, and it is definitely broken.

mmp2_pcm_mmap() is broken because it tries to call into the DMA API for providing a mapping. However, the memory area we use was not allocated with the DMA API, so that doesn't work. Instead we hardcode a memory area at 0xe0000000. Mitch says this is the address of the audio SRAM. If I understand it correctly, this is not actually DMA, it is CPU-driven access to the device memory.

Here's a patch which maps 0xe0000000 to userspace without using the DMA API.

[dsd]

use direct physical memory remapping to userspace

[dsd]

The patch is correct - Mitch cleared up our understanding. I'll commit it tomorrow with a better commit message, plus a fat comment explaining exactly whats going on here. In short, the audio DMA engine that we drive is simply for copying the data from the audio FIFO into audio SRAM, *not* for copying data into main memory. So the attempted use of the linux DMA API is incorrect here, since we aren't dealing with main memory.

[dsd]

pushed, along with added description.

gst-launch now works fine. Totem now works, with stop and start audio. Haven't tested Record, but it should work, even though it records silence. Memorize is working fine. Etoys doesn't fail as before, but fails at a later point according to Saadia.

[Quozl]

$ gst-launch audiotestsrc ! audioconvert ! audioresample ! alsasink

Works fine without error in 12.1.0 os9 XO-1.75 C2 SKU204.