I am implementing the application in Blackberry in which I start two threads, one thread constantly receives the UDP packets from the network and stores them in one common queue, another thread is of my player which playes data from this common queue. But in this implementation I some time get the data played, some time getting ControlledAccessException and sometime error 5. So what can be the reason?????
Any help.........
The ControlledAccessException can be thrown if you application doesn't have sufficient permissions to perform a certain operation. Go to the application settings and make sure everything is set to "allow" and see if that helps.
As for error 5 - if you're talking about an error thrown by the audio player (received by the PlayerListener), you can refer to this page for a reference on what the numeric error codes mean.
Related
I have a CoreAudio based player that streams remote mp3s.
It uses NSURLConnection to retrieve the mp3 data -> uses AudioConverter to convert the stream into PCM -> and feeds the stream into an AUGraph to play audio.
The player works completely fine in my demo app(it only contains a play button), but when i add the player to another project, but when coupled with a project that already makes networking calls, and updates UI, the player fails to play audio past a few seconds.
Am possibly experiencing a threading issue? What are some preventative approaches that i can take or look into that can prevent this from happening?
You do not mention anything in your software architecture about buffering your data between receiving it via NSURLConnection and when you send it to your player.
Data will arrive in chunks with inconsistent arrival rates.
Please see these answers I posted regarding buffering and network jitter.
Network jitter
and
Network jitter and buffering queue
In a nutshell, you can receive data and immediately send it to your player because the next data may not arrive in time.
You don't mention the rate that the mp3 file is delivered. If it is delivered very quickly over a fast connection... are you buffering all of the data received or is it getting lost somewhere in your app? There is a chance that your problem is that you are receiving way too much data too fast and not properly buffering up the data received.
I have been using CoreBlueTooth framework to communicate between BTLE iOS devices and I see a strange behavior. Here is what I am doing:
iOS device 1 (Peripheral): Expose a writable characteristics.
iOS device 2 (Central): Scan for the writable characteristics and write data into it.
iOS device 1 (Peripheral): Receives write request. Wait for some time to acknowledge the receipt of data.
iOS device 2 (Central): Get a callback on the below delegate and received the mentioned error.
Issue: Here if I respond back to the write request in few seconds by calling the API [iPeripheral respondToRequest:iRequest withResult:iStatus] then it all works fine and I get a success on my Central. But if I take some time, even if my Peripheral has not responded to the write request, I get error response back.
Is this some kind of connection loss in few seconds or the known CB framework behavior, any idea?
- (void)peripheral:(CBPeripheral *)iPeripheral didWriteValueForCharacteristic:(CBCharacteristic *)iCharacteristic error:(NSError *)iError
Error Domain=CBErrorDomain Code=0 "Unknown error." UserInfo=0x183a6d70 {NSLocalizedDescription=Unknown error.}
Both my Central and Peripheral are running on iOS 7.0.
I also observed this problem when I had deadlocks in my code and couldn't respond in time ;-) The way I observed it, iOS responds with an automatic error request with an arbitrary error code if a request is not answered within 10 seconds. I have not found a way to change this, but it makes sense from a protocol perspective.
In Bluetooth Low Energy, a central can only send a single Characteristic Value Write Request at a time. After it has sent this request, it cannot send a different Write Request unless the first one is responded to. Therefore, it is crucial to always respond to requests as fast as possible.
In the comments, you mentioned that you are waiting for user input to affect the result code you want to send to the central. I guess "Success" if the user confirms in the UI that an operation should be started, and an error code if the user denies that. This is not the way an LE based protocol should be designed. It's like blocking the UI thread until an operation is finished, just from the other side. You are effectively blocking the BT communications until a blocking operation (waiting for user input) completes.
A different design would be to send a write request to the other phone, responding immediately with a "Success" error code to indicate that the request was received and the popup is displayed. Then, send a Characteristic Value Indication with the user's choice from the peripheral to the central.
There's one small caveat if you target iOS 6: indications don't work nicely in many cases (reentrancy bugs etc, best not touch them). There, you should send a Read Request from your central and return the user's choice in this read request if it's already available. Again, don't block while giving the answer, sending back a "user is still choosing" value back if the answer is not yet ready.
Single rule: Answer requests as fast as possible. It's the way, Bluetooth LE is designed to work.
You may be exceeding the maximum time allowed for a write to be acknowledged. Try testing several different ack times and see if it reliably fails beyond a certain threshold.
If you use iPhone 4 devices, this device no suports BLE. BLS are supported in iPhone 4 and later.
In my app I am streaming audio and there is a period of 5-10 sec depending on the connection where the buffer is loading and after this, my app starts to play the audio. When it starts to play the audio this symbol comes up in the screen.
Here is an image of what im talking about.
http://img27.imageshack.us/img27/3667/img0596.png
I want to change a label in my app when this symbol comes up in the screen, but i dont know which function let me detect this.
The symbol is the "Play" button common to music devices. There is most likely an NSNotification center message that can be "listened for". However, depending on how you are buffering your sounds there is probably a delegate that can notify a selector once it has begun playback. Without more details I can not give more detailed advice. If I were in your position I would take a very hard look at the API you are utilizing, most likely several methods exist to either post notification or send delegate messages notifying the state of the stream as well as playback. I have worked with some streaming audio API and I was able to get status of the buffer as well many other messages from the stream object(s). These are just part of good design, so most likely it is there.
I'm using CocoaLibSpotify and the SPPlaybackManager to stream Spotify music to my app. It works very well overall, but I'm experiencing some issues with the playback during other network activity.
Procedure:
(During audio playback) I'm firing a regular ASIHTTPRequest to a server.
When the request has finished, I'm making a number of Spotify searches using SPSearch.
On many devices (in particular iPhone 3GS), I'm getting massive "stuttering"/"skips"/"pauses" in the playback while the Searches are performed.
Earlier, I used regular ASIHTTPRequests instead of the SPSearch class, so I'm quite sure it's got to do with the overall network activity.
Also, the playback issues may appear while doing some other network activity on the device, i.e. loading a number of emails in the Mail app.
Threading?
I'm guessing this is some kind of threading issue (i.e. the audio is played back on the main thread or something), but I'm not sure exactly how to approach the issue... I've tried invoking SPPlaybackManager#playTrack:: on a background thread, but I guess the setup wasn't 100% correct (since the issues remained).
Does anyone have any pointers as to how I should move forward?
Both the audio delivery and audio playback in the classes supplied with CocoaLibSpotify are run on (different) background threads. However, SPPlaybackManager is only intended to be an easy-to-follow example of dealing with audio playback using Core Audio - it hasn't been tested for, nor is it intended for, use during high CPU load and/or in environments very tight on resources.
All I can do is point you towards the standard debugging tools such as Instruments to trace and profile what's going on.
I have a Application on a PC which displays time-information for a mp3 song that is played. I now need to display this time information within an iPad App. The counting timers for remaining time, player position and song length must be in sync between iPad an PC.
I thought about using a socket connection (AsyncSocket on iPad) to keep the counters in sync.
Is there a better way doing this? I don't want to run in the wrong direction...
Additional, it should be possible to have more than one iPad showing the Information in future. That's a "nice to have" feature...
I don't need ready to use code snippets, it's more a theoretical question. (if someone has a ready to use code snippet, that's also good for me :-) )
MadMaxApp
i now used the AsyncSocket to solve the requirements. It works perfectly. Don't forget the handling of closing the socket connection if the app goes in background. Depending on the server the app is talking with, not closing the socket can lead to a problem in reconnecting.