Layout on Mini is broken
Hi. I've got an iOS 6.1 iPad app that lays out fine in the iPad sim and on a Retina iPad device. On the Mini, however, it gets really wonky, sometimes. See here: http://cl.ly/image/2Q0p2z3x0D3S (I've crudely erased our giant logo from the center of the screen and our app name from the center of the top bar.) Sometimes, the top is okay, but the toolbar along the bottom is shifted upward about a toolbar width. The "215 MiB" is a separate view on top of the top toolbar. The icons on the left and right, and the title in the center, are UIBarButtonItem elements in the toolbar. Any idea what's going on? -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OutlineView shouldSelectItem Being Called Twice
On 05/06/2013, at 11:56 AM, Chris Tracewell wrote: > Is this normal behavior? Thanks for the help. Probably. This method should just answer the question, not attempt to interrupt things by showing an alert etc. You'll need to put that functionality elsewhere. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
OutlineView shouldSelectItem Being Called Twice
I've got a view controller set up as the delegate for an outlineView. The view
controller implements the -(BOOL)outlineView:(NSOutlineView *)outlineView
shouldSelectItem:(id)item delegate method. I show an alert and return NO if the
user has not saved some changes or return YES if all is well. The problem is
that when I return no the delegate method fires twice. Even when I strip out
all of my code and just log the method as shown below it shows two calls.
Returnign YES works fine. I thought maybe it's because it was firing once for
the original election change and then again to return back to the original
selection but logging "item" showed its the same row for both calls.
-(BOOL)outlineView:(NSOutlineView *)outlineView shouldSelectItem:(id)item
{
NSLog(@"firing");
return NO;
}
Is this normal behavior? Thanks for the help.
-CT
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Can using iOS camera without preview, cause app store submission problem?
[I'm only now (4-Jun-2013) receiving questions from the end of May. I'm sorry if I'm reviving issues that have already had better answers.] On 29 May 2013, at 10:38 AM, Johannes Kalev wrote: > I'm writing an iOS application which is supposed to read QR code from an > accessory. Currently I'm using camera in such a way that camera preview is > not displayed to a user while scanning for a QR code on an image received > from camera. > > I'm wondering if not showing preview of camera to a user can cause an iOS > app store submission problems? (I'm assuming "reading a code from an accessory" means that the code is presented by the accessory to be read by the device's camera.) That sort of issue is unpredictable. The guidelines (in paraphrase) say that apps with serious usability issues will be rejected. In my experience of QR scanner apps, not letting the user see whether the code is properly sized, lighted, deskewed, focused, or even on-camera would be a serious usability issue. But that would depend on the inclinations of a particular reviewer on a particular day. Reviewers sometimes disregard even explicit guidelines. My guess: Expect approval, but reserve time in your schedule to fix it. — F -- Fritz Anderson Xcode 4 Unleashed: 4.5 supplement for free! http://www.informit.com/store/xcode-4-unleashed-9780672333279 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: A question about NSScreen being autoreleased during loadNib()
On 28 May 2013, at 5:50 AM, "Jacky.Seraph Mu" wrote: [On a Retina machine, after instantiating an NSWindow from a new window controller, an NSScreen pointer obtained earlier from another window/controller apparently is released, and the debugger shows funny values in its struct members. The backtrace identified with the screen release shows it happens in a cascade from an NSArray, which I'd wager is the static NSScreen screen list.] Random comments, most of which are merely suggestive, and some of which you will say are obviously wrong-headed; but if everything you thought was impossible was in fact impossible, you wouldn't have a bug: You don't outright say what the consequence of the strange behavior is. Do you crash? Where? I'd not be surprised if NSScreen on HiDPI machines worked differently than on "normal" ones. The struct members aren't API, and don't necessarily mean what they obviously meant in earlier versions. Are you using ARC? If not, do you -retain the screen object while you are interested in it? It would be strange if the current autorelease pool were drained in the course of the code you show, but not impossible. If you're not using ARC, have you tried zombie detection? Have you run the application against the Allocations instrument, with full retain/release histories captured? Does the other debugger (lldb vs gdb) help? Just for grins, what do you get when you "po screen"? If it's still an NSScreen, or apparent subclass, overrelease isn't your problem. Are you accessing the passed-in NSScreen pointer after the line you flag? How? Does it become "normal" then? What do you get if you acquire a fresh NSScreen pointer? Compared to the new value? Compared to the one before the putative release? I believe sending -window to your controllers will instantiate the windows. What leads you to believe that window.screen is valid at the time you call it? Is the window on-screen then? This is wild even for me, but do you make _any_ changes to the display parameters between the time you acquire the pointer and the time you discover the fault? The API does not _promise_ that NSScreen objects will be per-screen singletons; a change in display configuration might result in the screen list being thrown away. (I'd be astonished if that were so, but there is no contract that it not be.) — F -- Fritz Anderson Xcode 4 Unleashed: 4.5 supplement for free! http://www.informit.com/store/xcode-4-unleashed-9780672333279 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory not being released in a timely manner
On Jun 4, 2013, at 8:30 AM, Jeff Johnson wrote: > The "end" of the event loop cycle is immediately before the beginning. Thus, > for example, if your app is in the background and not receiving events, then > the autorelease pool will not be drained. You can work around this by wrapping your own autorelease pools around code that allocates significant amounts of memory, rather than relying on the runloop’s outer autorelease pool to free it for you. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory not being released in a timely manner
On Jun 3, 2013, at 8:59 AM, Jonathan Taylor wrote: > The program loads and processes a large number (~2000) image files, and I > believe that I am disposing of memory and draining autorelease pools > correctly. Running the program under ObjectAlloc, it never reports memory > usage over 300MB. I don’t know if ObjectAlloc is supported anymore; you should be using Instruments. It’s been a long time since I used that app, so I don’t know if it reports all heap allocations or just Obj-C objects. The problem is that a small object (like an NSImageRep) can be hanging onto huge memory buffers for pixels. > The problem seems to be that, even though ObjectAlloc thinks the memory has > been released, it is not actually being properly freed up until some time > later. The memory usage as reported in Activity Monitor climbs higher and > higher until, if left unattended, there is apparently no more memory > available. There are a lot of different numbers measuring different kinds of memory usage, and not all of them are relevant to this. What specific value in Activity Monitor are you talking about? The most relevant one is Private Mem (RPRVT). —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using AVFoundation with AVCaptureAudioDataOutput for Audio playback
You should ask about audio questions on the coreaudio-dev list, not here. I don’t think the audio experts read this list. (It’s only recently that there have been real Cocoa-level APIs for audio at all.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory not being released in a timely manner
Hi Jeff, Thanks very much for your reply. That's brilliant. I had tried playing around with a few "tricks" I thought might prompt a pool drain, but to no joy. It's great to have a bit of code that will do the job for that - I'll give it a go tomorrow. Cheers Jonny On 4 Jun 2013, at 16:30, Jeff Johnson wrote: > Hi Johnny. > > This is a long-standing problem with AppKit. According to the documentation, > "The Application Kit creates an autorelease pool on the main thread at the > beginning of every cycle of the event loop, and drains it at the end, thereby > releasing any autoreleased objects generated while processing an event." > However, this is somewhat misleading. The "end" of the event loop cycle is > immediately before the beginning. Thus, for example, if your app is in the > background and not receiving events, then the autorelease pool will not be > drained. That's why your memory drops significantly when you click the mouse > or switch applications. > > We've run into this issue in a number of apps. As a workaround, we add a > timer to the main thread and have it fire periodically. The timer's action > method does the following: > > NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined > location:NSZeroPoint modifierFlags:0 timestamp:[NSDate > timeIntervalSinceReferenceDate] windowNumber:0 context:nil subtype:0 data1:0 > data2:0] > [NSApp postEvent:event atStart:YES]; > > This basically "tickles" the event loop and causes the autorelease pool to > drain. > > -Jeff > > > On Jun 3, 2013, at 10:59 AM, Jonathan Taylor > wrote: > >> Hi all, >> >> Can anybody advise what tools I should be using to debug a particular out of >> memory condition - and maybe even how I can fix it? The error that I >> ultimately encounter (in a 32-bit application on Snow Leopard) is: >> 2013-06-03 15:44:30.271 MyApplication[25115:a0f] NSImage: Insufficient >> memory to allocate pixel data buffer of 1228800 bytes >> However as I'll explain I don't feel that I am doing anything that should >> result in running out of memory. >> >> The program loads and processes a large number (~2000) image files, and I >> believe that I am disposing of memory and draining autorelease pools >> correctly. Running the program under ObjectAlloc, it never reports memory >> usage over 300MB. The problem seems to be that, even though ObjectAlloc >> thinks the memory has been released, it is not actually being properly freed >> up until some time later. The memory usage as reported in Activity Monitor >> climbs higher and higher until, if left unattended, there is apparently no >> more memory available. Clicking the mouse or switching applications causes >> an immediate and significant drop in memory usage. >> >> Thus the situation seems to be that I believe I am doing everything I can >> for good memory management, but the OS is not actually freeing things up for >> re-use. I encountered a similar problem that I asked about on here last year: >> http://lists.apple.com/archives/cocoa-dev/2012/Jul/msg00602.html >> Although in that case the eventual conclusion was that I should be using a >> different approach in my code, it involved the same issue of memory not >> being released when I would have expected it to be. In that case from last >> year, I was wrong to rely on it being released when I expected, but I feel >> that this time it should be reasonable to expect that I won't run out of >> memory entirely, given that I am releasing all the buffers that I am >> finished with and only keeping a small working set allocated! >> >> This is of course partly just speculation because ObjectAlloc isn't giving >> any info about this unavailable but apparently not-allocated memory. So... >> 1. Can anybody recommend a way of debugging this problem to get more >> concrete evidence for what is actually happening? >> 2. Assuming my interpretation is correct, can anybody suggest a solution? >> >> Many thanks >> Jonny > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory not being released in a timely manner
On Jun 3, 2013, at 8:59 AM, Jonathan Taylor wrote: > ...The memory usage as reported in Activity Monitor climbs higher and higher > until, if left unattended, there is apparently no more memory available. > Clicking the mouse or switching applications causes an immediate and > significant drop in memory usage…. I've seen this problem with GCD's handling of autorelease pools. It sounds very similar to what Jeff said, but I've only experienced it on 10.6, with 10.7+ behaving as desired. -- Seth Willits ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Memory not being released in a timely manner
Hi Johnny. This is a long-standing problem with AppKit. According to the documentation, "The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event." However, this is somewhat misleading. The "end" of the event loop cycle is immediately before the beginning. Thus, for example, if your app is in the background and not receiving events, then the autorelease pool will not be drained. That's why your memory drops significantly when you click the mouse or switch applications. We've run into this issue in a number of apps. As a workaround, we add a timer to the main thread and have it fire periodically. The timer's action method does the following: NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined location:NSZeroPoint modifierFlags:0 timestamp:[NSDate timeIntervalSinceReferenceDate] windowNumber:0 context:nil subtype:0 data1:0 data2:0] [NSApp postEvent:event atStart:YES]; This basically "tickles" the event loop and causes the autorelease pool to drain. -Jeff On Jun 3, 2013, at 10:59 AM, Jonathan Taylor wrote: > Hi all, > > Can anybody advise what tools I should be using to debug a particular out of > memory condition - and maybe even how I can fix it? The error that I > ultimately encounter (in a 32-bit application on Snow Leopard) is: > 2013-06-03 15:44:30.271 MyApplication[25115:a0f] NSImage: Insufficient memory > to allocate pixel data buffer of 1228800 bytes > However as I'll explain I don't feel that I am doing anything that should > result in running out of memory. > > The program loads and processes a large number (~2000) image files, and I > believe that I am disposing of memory and draining autorelease pools > correctly. Running the program under ObjectAlloc, it never reports memory > usage over 300MB. The problem seems to be that, even though ObjectAlloc > thinks the memory has been released, it is not actually being properly freed > up until some time later. The memory usage as reported in Activity Monitor > climbs higher and higher until, if left unattended, there is apparently no > more memory available. Clicking the mouse or switching applications causes an > immediate and significant drop in memory usage. > > Thus the situation seems to be that I believe I am doing everything I can for > good memory management, but the OS is not actually freeing things up for > re-use. I encountered a similar problem that I asked about on here last year: > http://lists.apple.com/archives/cocoa-dev/2012/Jul/msg00602.html > Although in that case the eventual conclusion was that I should be using a > different approach in my code, it involved the same issue of memory not being > released when I would have expected it to be. In that case from last year, I > was wrong to rely on it being released when I expected, but I feel that this > time it should be reasonable to expect that I won't run out of memory > entirely, given that I am releasing all the buffers that I am finished with > and only keeping a small working set allocated! > > This is of course partly just speculation because ObjectAlloc isn't giving > any info about this unavailable but apparently not-allocated memory. So... > 1. Can anybody recommend a way of debugging this problem to get more concrete > evidence for what is actually happening? > 2. Assuming my interpretation is correct, can anybody suggest a solution? > > Many thanks > Jonny ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: TECConvertText returns an unknown result code
On Tue, 4 Jun 2013 16:00:54 +0200, Thierry Cantet said: >It returns the result code -50 (result code that doesn't appear in the >lists of the result codes of this function ( >https://developer.apple.com/library/mac/#documentation/Carbon/Reference/ >Text_Encodin_sion_Manager/Reference/reference.html >) > >What does this -50 can mean ? Go to Terminal and type: $ macerror -50 Mac OS error -50 (paramErr): error in user parameter list See also MacErrors.h. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
TECConvertText returns an unknown result code
Hello. I have an issue with TECConvertText ( https://developer.apple.com/library/mac/#documentation/Carbon/Reference/Text_Encodin_sion_Manager/Reference/reference.html ). It returns the result code -50 (result code that doesn't appear in the lists of the result codes of this function ( https://developer.apple.com/library/mac/#documentation/Carbon/Reference/Text_Encodin_sion_Manager/Reference/reference.html ) What does this -50 can mean ? Thanks in advance ! -- Thierry CANTET ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Memory not being released in a timely manner
Hi all, Can anybody advise what tools I should be using to debug a particular out of memory condition - and maybe even how I can fix it? The error that I ultimately encounter (in a 32-bit application on Snow Leopard) is: 2013-06-03 15:44:30.271 MyApplication[25115:a0f] NSImage: Insufficient memory to allocate pixel data buffer of 1228800 bytes However as I'll explain I don't feel that I am doing anything that should result in running out of memory. The program loads and processes a large number (~2000) image files, and I believe that I am disposing of memory and draining autorelease pools correctly. Running the program under ObjectAlloc, it never reports memory usage over 300MB. The problem seems to be that, even though ObjectAlloc thinks the memory has been released, it is not actually being properly freed up until some time later. The memory usage as reported in Activity Monitor climbs higher and higher until, if left unattended, there is apparently no more memory available. Clicking the mouse or switching applications causes an immediate and significant drop in memory usage. Thus the situation seems to be that I believe I am doing everything I can for good memory management, but the OS is not actually freeing things up for re-use. I encountered a similar problem that I asked about on here last year: http://lists.apple.com/archives/cocoa-dev/2012/Jul/msg00602.html Although in that case the eventual conclusion was that I should be using a different approach in my code, it involved the same issue of memory not being released when I would have expected it to be. In that case from last year, I was wrong to rely on it being released when I expected, but I feel that this time it should be reasonable to expect that I won't run out of memory entirely, given that I am releasing all the buffers that I am finished with and only keeping a small working set allocated! This is of course partly just speculation because ObjectAlloc isn't giving any info about this unavailable but apparently not-allocated memory. So... 1. Can anybody recommend a way of debugging this problem to get more concrete evidence for what is actually happening? 2. Assuming my interpretation is correct, can anybody suggest a solution? Many thanks Jonny ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Using AVFoundation with AVCaptureAudioDataOutput for Audio playback
Hello
I am trying to write an external plugin that simply reads audio from the built
in microphone, obtains the raw audio data, and passes it to an SDK API.
My setup is very simple, I have a single session, with a single input device
(built in microphone) and a single output (AVCaptureAudioDataOutput)
I Initialize the Session, Input, and Output as follow:
// Obtain the device and retain it
_pAudioCaptureInput = [pAVInputDevice retain];
// Initialize Capture Session
_dispatchQueue = dispatch_get_main_queue();
_pCaptureSession = [[AVCaptureSession alloc] init];
_pCaptureSession.sessionPreset = AVCaptureSessionPresetHigh;
// Put the Device inside an Input
pInputDevice = [[AVCaptureDeviceInput alloc]
initWithDevice:_pAudioCaptureInput error:&pError];
[_pCaptureSession addInput:pInputDevice]; // Add Audio Input to
Session
[pInputDevice release];
pInputDevice = nil;
// Setup the Output Configurations
NSDictionary *pAudioSettings = [NSDictionary
dictionaryWithObjectsAndKeys:
[NSNumber
numberWithInt:kAudioFormatLinearPCM], AVFormatIDKey,
[NSNumber
numberWithInt:44100], AVSampleRateKey,
[NSNumber numberWithInt:2],
AVNumberOfChannelsKey,
[NSNumber numberWithInt:16],
AVLinearPCMBitDepthKey,
[NSNumber
numberWithBool:NO], AVLinearPCMIsFloatKey,
[NSNumber
numberWithBool:NO], AVLinearPCMIsBigEndianKey,
nil];
// Create the Output
_pAudioCaptureOutput = [[AVCaptureAudioDataOutput alloc] init];
[_pAudioCaptureOutput setAudioSettings:pAudioSettings]; // Apply
Output Settings
[_pCaptureSession addOutput:_pAudioCaptureOutput]; // Add Output to
Session
// Create the Output Delegate that will receive the SampleBuffer
callbacks
_pAudioCaptureDelegate = [[ACaptureDelegate alloc] init];
[_pAudioCaptureOutput setSampleBufferDelegate:_pAudioCaptureDelegate
queue:_dispatchQueue];
// Remember the Device Name
_deviceName = [_pAudioCaptureInput.localizedName UTF8String];
I start the session running by calling startRunning on the session. My
callback delegate is notified with Audio Samples. The follow is the callback
implementation:
- (void)captureOutput:(AVCaptureOutput *)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer
fromConnection:(AVCaptureConnection *)connection
{
// Save the Timescale
CMTime timestamp =
CMSampleBufferGetOutputPresentationTimeStamp(sampleBuffer);
if(_timescale == -1) {
_timescale = timestamp.timescale;
}
CMItemCount numSamples = CMSampleBufferGetNumSamples(sampleBuffer);
// Get Audio Data
CMBlockBufferRef dataBuffer = CMSampleBufferGetDataBuffer(sampleBuffer);
zuint32 dataLength = CMBlockBufferGetDataLength(dataBuffer);
AVCaptureAudioDataOutput *pOutput = static_cast(captureOutput);
NSDictionary *pAudioSettings = pOutput.audioSettings;
// Retrieve Audio Settings Information from AVOutputDevice
NSNumber *audioSettingValue = nil;
zint32 sampleRate = 44100;
audioSettingValue = [pAudioSettings objectForKey:AVSampleRateKey];
if(audioSettingValue) {
sampleRate = [audioSettingValue intValue];
}
zint32 bitDepth = 16;
audioSettingValue = [pAudioSettings objectForKey:AVLinearPCMBitDepthKey];
if(audioSettingValue) {
bitDepth = [audioSettingValue intValue];
}
zint32 channels = 2;
audioSettingValue = [pAudioSettings objectForKey:AVNumberOfChannelsKey];
if(audioSettingValue) {
channels = [audioSettingValue intValue];
}
zuint8 *pAudioData = new zuint8[dataLength];
OSStatus err = CMBlockBufferCopyDataBytes(dataBuffer, 0, dataLength,
pAudioData);
if(err == noErr) {
// Populate SDK Audio structure
_audioBuffer.format = kFormatPCM;
_audioBuffer.dataLength = dataLength;
_audioBuffer.timeStamp = 0;
_audioBuffer.flags = kBufferFlagTimeValid;
_audioBuffer.sampleRate = sampleRate;
_audioBuffer.bitsPerSample = bitDepth;
_audioBuffer.channels = channels;
_audioBuffer.data = pAudioData; // The Raw Audio Data
// Send Audio Data to SDK API
_pAudioDataArriveCallback(_pAudioDataArriveContext, &_audioBuffer);
delete [] pAudioData;
pAudioData = NULL;
}
}
The Problem is, the audio is playing back with a higher pitch. L
Can using iOS camera without preview, cause app store submission problem?
Hi, I'm writing an iOS application which is supposed to read QR code from an accessory. Currently I'm using camera in such a way that camera preview is not displayed to a user while scanning for a QR code on an image received from camera. I'm wondering if not showing preview of camera to a user can cause an iOS app store submission problems? Thanks in advance, Johannes ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
A question about NSScreen being autoreleased during loadNib()
Hi,
I am OSX developer. The problem I encountered is described as below:
- (void)method1:(NSObject *)arg1
contextInfo:(NSObject *)arg2
{
...
[self method2:arg1
screen:[self.windowController window].screen];
...
}
- (void)method2:(NSObject *)arg1
screen:(NSScreen *)screen
{
...
MyWindowController *myWindowController =
[[MyWindowController alloc] initWithWindowNibName:@"MyWindow"];
NSWindow *aWindow = [MyWindowController window]; // A Problem happens
...
}
After executed the line "A Problem happens", I found that the content of
the screen (that is, the *screen) changed.
(gdb) p *screen
$15 = {
= {
isa = 0x7fff788a6598 changed
},
members of NSScreen:
_frame = {
origin = {
x = -4353346, xxx changed
y = -234234
},
size = {
width = -35252435, changed
height = -3452663, changed
}
},
_depth = 520,
_screenNumber = 2077752383,
_auxiliaryStorage = 0x0
}
At the very beginning, I thought there could have been a stack overflow or
memory corruption that resulted in this issue. But then I used gdb to watch
the when *screen is changed. And I also thought that perhaps due to a
memory corruption, screen has been released unexpectedly. So I also
rwatched the screen and *screen. But what I got is only that:
(Please forgive me changed some log because I cannot release the code here.)
#0 0x7fff8427824f in objc_msgSend ()
#1 0x7fff8c5748e4 in -[NSScreen dealloc] ()
#2 0x7fff8581528a in CFRelease ()
#3 0x7fff85852efc in -[__NSArrayI dealloc] ()
#4 0x7fff8427c230 in (anonymous namespace)::AutoreleasePoolPage::pop ()
#5 0x7fff8583cd72 in _CFAutoreleasePoolPop ()
#6 0x7fff8c07c172 in loadNib ()
#7 0x7fff8c07b88c in +[NSBundle(NSNibLoading)
_loadNibFile:nameTable:withZone:ownerBundle:] ()
#8 0x7fff8c1ce5bc in +[NSBundle(NSNibLoading)
loadNibFile:externalNameTable:withZone:] ()
#9 0x7fff8c20160b in -[NSWindowController loadWindow] ()
#10 0x7fff8c2012e5 in -[NSWindowController window] ()
#11 0x00010003c3c9 in -[SessionListener method2:screen:]
(self=0x10220caa0, _cmd=0x100261922, arg1=0x10209ede0, screen=0x1020b7d20)
at SessionListener.m:307
#12 0x00010003d3f4 in -[SessionListener method1:contextInfo:]
(self=0x10220caa0, _cmd=0x1002618a0, arg1=0x10206b950, arg2=0x0) at
SessionListener.m:457
The rwatch and watch were set at the very beginning of the method2 being
executed.
Then I got the first break while executing the "A Problem happens"line with
above stack trace.
>From my observing, the loading of the window seemed to trigger an
Autorelease cycle that released the NSScreen.
But I didn't do anything like autoreleasepool drain or release. So I
wondered why it happened that way.
The last thing is that, this issues doesn't always happen. It is very easy
to reproduce this issue on my 13 and 15 inch retina MBPs(OSX 10.8.2) but
cannot repro on my other 13 inch MBP non-retina (OSX10.8.2).
Could any one leave a comment?
Thanks,
Jack.Seraph
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
