• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: memcpy woes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: memcpy woes


  • Subject: RE: memcpy woes
  • From: pollock mcgee <email@hidden>
  • Date: Thu, 18 Aug 2011 11:37:33 +0000
  • Importance: Normal

Thanks very much, you have saved me at least another week of staring blindly at it wishing it would work.

I think his code is for teaching purposes so he could be more explicit with what was actually happening. At the end of the file there is a horrible sound as the buffer runs off into uncharted territory  but i'm not too bothered about that i just needed to know it worked so I could use it in my own ring buffer code. 

I noticed that the code speeds up the audio. If you replace

 musicPlaybackState->samplePtr += inNumberFrames * sizeof(AudioSampleType); 

with

musicPlaybackState->samplePtr += inNumberFrames;

because it is a pointer you only need to give the index and not the entire offset in bytes
just thought id clarify that in case anyone else benefits from this code.

All the best

Pollock


Subject: Re: memcpy woes
From: email@hidden
Date: Wed, 17 Aug 2011 20:42:30 -0700
CC: email@hidden
To: email@hidden

You're on the right track, it's weird that he uses a memcpy per sample, a single memcpy will take care of this as long as the data formats are the same.

You could do something like this:

AudioSampleType *sample = musicPlaybackState->samplePtr;
AudioBuffer buf = ioData->mBuffers[0];

memcpy(buf.mData, sample, inNumberFrames * sizeof(AudioSampleType));


musicPlaybackState->samplePtr += inNumberFrames * sizeof(AudioSampleType);



But there might be bigger problems already, for example samplePtr is modified in this audio callback thread. So what happens when it runs out of data, you can't modify it from another thread and expect good things. Better to use a lockless ringbuffer.

Also, always check the number of buffers and the sizes and whether it contains interleaved stereo data instead of blindly writing to it.


On Aug 17, 2011, at 6:23 AM, pollock mcgee wrote:

MusicPlaybackState *musicPlaybackState = (MusicPlaybackState*) inRefCon;


AudioSampleType *sample = musicPlaybackState->samplePtr;
size_t count= 2;
AudioBuffer buf = ioData->mBuffers[0];

for (int currentframe=0; currentframe<inNumberFrames; currentframe++) {

 

memcpy(buf.mData + ((currentframe)*(2)),
   sample,
   count);


sample ++;
musicPlaybackState->samplePtr = sample;
}



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >memcpy woes (From: pollock mcgee <email@hidden>)
 >Re: memcpy woes (From: Hamilton Feltman <email@hidden>)

  • Prev by Date: Re: memcpy woes
  • Next by Date: Re: AudioUnitKernal constructor called twice...
  • Previous by thread: Re: memcpy woes
  • Next by thread: AMR-NB in Lion
  • Index(es):
    • Date
    • Thread