On Wed, 2011-08-17 at 13:34 +0530, kuldeep ghan wrote:
> Hi,
>
> I am working on a setup which has Linux Kernel running and I have
> pulseaudio as Sound server. ASoc Alsa driver snd_pcm_mmap function
> returns me
> Virtual Memory mapped to physical memory which is strictly 32 Bit
> Aligned.
Out of curiosity, what platform is this?
> When I am trying to Mix two streams with gst-launch, pa_mix function
> tries to write 16Bit mixed samples to this physical memory resulting
> in Bus error.
>
> As a work around I am trying following code which is trying to write
> two Mixed 16Bit samples write making it a 32Bit write.
> src/pulsecore/sample-util.c
>
> // *((int16_t*) data) = (int16_t) sum;
> if(j==0) {
> temp[0]=(int16_t) sum;
> j=1;
> } else {
> temp[1]=(int16_t) sum;
> j=0;
> sum = ((temp[1] << 16) | (0x0000FFFF &
> temp[0]));
>
> data = (uint8_t*) data - sizeof(int16_t);
> *((int32_t*) data) = (int32_t) sum;
> data = (uint8_t*) data + sizeof(int16_t);
> }
>
> With this I am able to mix a gst-launch stream and already loaded
> sample from pulseaudio played with play-sample from pacmd.
> But not able to mix two streams with gst-launch.
What is the error you see when playing 2 streams? Do two instances of
paplay work fine together?
BTW, Another potential workaround (if your hardware supports it), is to
force the default sample spec to use S32NE samples (you can edit the
default value in /etc/pulse/daemon.conf). The downside is obviously that
you're transferring 2x the amount of data that you'd have done with
S16LE samples and the format conversion cost for just about every
client.
Unless there's more hardware out there with this sort of limitation (I
don't believe there is), I wouldn't be too keen on adding this sort of
workaround upstream.
Regards,
Arun
