I created a project in which I have included various audio AudioUnit type: generator, mix, highpass, IOU in Augraph enviroments. I can get working almost everything I had planned for the app, but I can not explain why I can hear the fileplayer with the (action auGraphStart), but if I press the action (augraphStop) and then again (auGraphStart) this action does not resume audio. the only thing I can hear after pressing start again is a small chunk of audio and then total silence.
can you put me in right direction to solve this issue?
Related
I implementing webRTC with socket.io with for signaling, but earlier as soon as I opened the URL it used to give screeching sound, but then after some research, I added a muted attribute in the local video tag so it got fixed but now when I call someone then both the browser have a high pitched screeching sound(less on macOS chrome and more on android chrome), the code which I using as a basis is from this tutorial, I modified the code on line 148 to have audio: true and the HTML video tag for the local video to have muted, rest of the code is exactly same as the repo.
I have read a lot of articles on it but I am not able to find a solution to the screeching. Any help would be appreciated, Thanks.
If both the devices are near to each other, then it causes this sound. If you move the devices far away, then there won't be screeching sound...
This happens with other video chat applications like zoom and google-meet also...
Every time I'm working on a Core Audio application, specifically one that utilizes real-time audio via the remoteIO audio unit render callbacks, the moment I start the audio unit engine running whatever music I am playing via youtube or itunes is muted. I must reload the youtube page or reset my system preference audio settings to get sound back. Is there a solution to this?
Set the mix-with-others property on the Simulator's RemoteIO Audio Unit before starting it. Also enable a proper AVAudioSession category.
I'm using Qt 5.1 (from here) on a MacBook Pro (OSX 10.8.4).
I have a movie player application consisting of little more than a QMediaPlayer and a QVideoWidget. Video from a local file URL plays fine.
I can connect and monitor the player's mediaStatusChanged and positionChanged signals, and increase the rate at which they're reported with QMediaPlayer::setNotifyInterval to several times per second.
This all seems to work fine except for one annoying thing:
When the player reaches the end of the file, it doesn't change status, it just reports the same position repeatedly. Only (and this is where things get strange) if I resize the window or minimise/maximise it, does it seem to "flush out" the expected status change to QMediaPlayer::EndOfMedia. Even just raising another application to cover the video app seems to flush the status change.
Any suggestions? Bug in QMediaPlayer? Me doing something wrong? Suggestions for workrounds?
Update: Now reported in Qt Jira.
I'm using BackgroundAudioPlayer for my Windows Phone 7 music & video application. After I play some music, I play video using MediaPlayerLauncher, then press Back to return to my app. There whenever I use BackgroundAudioPlayer.Instance. I receive error "The background audio resources are no longer available".
Someone on MSDN suggests using try/catch, but this is not a good idea, and can slow down the app.
Other suggests call BackgroundAudioPlayer.Instance.Close() before launch MediaPlayer. However, when I play music, the agent load .dll again, which takes very much time.
How to fix this ?
If you play a video after your audio the OS will definitely "terminate" your Background Audio Player. From your question it seems this is reproducible 100% of the time which would confirm this. Your only option is to restart the background audio player again after you have called BackgroundAudioPlayer.Instance.Close(), and then played your video. Which as you said will require reloading your player DLL when you start the BAP.
Update following up from comments
If you aren't implementing a streaming audio agent but only an AudioPlayer agent there isn't a process for you to kill anyway. The OS spins up a process as and when it needs to get you to process an action (e.g.: user action, track ended, shutdown).
BackgroundAudioPlayer.Instance.Close() just makes sure that the OS releases those resources cleanly in a scenario such as the OP has.
To restart background audio, just call BackgroundAudioPlayer.Instance.Play() again.
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.