In my attempts to troubleshoot a challenging SpeechRecognizer.java issue, I noticed in Logcat messages TAGs that are not SpeechRecognizer's:
12:34:00.933 NetworkSpeechRecognizer pid-29210 I Online recognizer - start listening
12:34:00.936 SodaSpeechRecognizer pid-29210 I Offline recognizer - start listening
12:34:00.936 SodaSpeechRecognizer I Initialize Soda [locale: en-US]
12:34:00.963 SodaSpeechRecognizer I Initialize Soda with language pack directory
12:34:01.099 SodaSpeechRecognizer I Offline recognizer - start detection
12:34:02.975 NetworkSpeechRecognizer I #cancel
12:34:02.976 NetworkSpeechRecognizer pid-29210 I #cancel
12:34:02.976 NetworkSpeechRecognizer I #failWithException
12:34:02.977 SodaSpeechRecognizer I startDetection successful
12:34:02.979 NetworkSpeechRecognizer W Recognizer network error
12:34:02.979 SodaSpeechRecognizer I Offline recognizer - stop detection
What is SodaSpeechRecognizer?
Where can I learn more about it?
How are these tags generated if SpeechRecognizer.java only defines:
private static final String TAG = "SpeechRecognizer";
Update: I just found this article SODA: Speech On-Device API along with this page. Nice clue, but insufficient as this is not official documentation.
The following official documentation from Google seems to be much better: https://cloud.google.com/speech-to-text/priv/docs/ondevice-overview
Yet, it is still mysterious, quoting:
This product is a private feature. The documentation is publicly
available but you must contact Google for full access.
Attempting to answer my questions (until a better answer comes along):
SodaSpeechRecognizer is the on-device speech recognizer (SODA is an acronym for "Speech On-Device API"). It is unclear yet when it was introduced. Could this be with the introduction of com.google.android.googlequicksearchbox(Android 4.1 AKA "Jelly Bean", released in June 2012)?
The best way to learn about it is at https://cloud.google.com/speech-to-text/priv/docs/ondevice-overview . One must contact Google for full access, though.
Those tags were likely defined in a C++ module name soda_async_impl.cc, as it is the only one visible on Logcat that produces SODA related messages:
native W W0206 12:01:28.459973 32167 soda_async_impl.cc:320] Creating soda_impl.
W W0206 12:01:28.460534 32167 soda_async_impl.cc:322] Created with thread priority 10
native W W0206 12:01:29.632099 32167 soda_async_impl.cc:484] SODA session starting (require_hotword:0, hotword_timeout_in_millis:0, trigger_type:TRIGGER_TYPE_UNSPECIFIED, hybrid_asr_config.mode:MODE_DEFAULT)
native W W0206 12:01:29.634873 32200 soda_async_impl.cc:1203] SODA received first mic audio buffer, size in bytes: 320, format: 1, channels: 1, : sample rate: 16000
native W W0206 12:01:30.154026 32200 soda_async_impl.cc:959] Not receiving any loopback audio in 500ms. Last audio received time: 0, Current time in us: 1675677690154022
native W W0206 12:01:33.162399 32200 soda_async_impl.cc:861] SODA stopped processing audio, mics audio processed in millis: 4880, loopback audio processed in millis: 0
W W0206 12:01:33.265670 32200 soda_async_impl.cc:916] SODA session stopped due to: MIC_END_OF_DATA
W W0206 12:01:33.319812 32171 soda_async_impl.cc:987] Deleting soda_impl
Related
I'm porting a game to Quest and so part of my work is to interface the engine's Vulkan renderer w/ the Oculus Mobile SDK.
I believe I'm setting up the SDK correctly (I'm following the examples and the guidelines from Oculus' docs) but still I'm getting a nasty error when trying to submit a frame.
Here's a high-level list of the things I'm currently doing:
I initialize the API.
I create a Vulkan instance and device w/ the expected extensions.
I acquire per-eye swapchains and get Vulkan handlers for each of their images.
I setup framebuffers and renderpasses using those images.
I acquire a native android window.
I enter VR mode (making sure the app is resumed).
Then at the end of my render loop I setup an ovrSubmitFrameDesc and then call vrapi_SubmitFrame2(). I'm also making sure I only call vrapi_SubmitFrame2() after all work has been submitted to the GPU (I'm currently using a fence on my work queues).
However, as I mentioned before, the call to vrapi_SubmitFrame2() fails. It currently raises a SIGSEGV inside Quest's Vulkan driver:
backtrace:
#00 pc 000000000010b2d8 /vendor/lib64/hw/vulkan.kona.so (!!!0000!b78ad09fc24eab751708d0a80613cf!09c6a36!+24) (BuildId: cc478ff923cc27b87607fb1f1a3b87ef)
#01 pc 00000000000c3b04 /vendor/lib64/hw/vulkan.kona.so (qglinternal::vkQueueSubmit(VkQueue_T*, unsigned int, VkSubmitInfo const*, VkFence_T*)+4468) (BuildId: cc478ff923cc27b87607fb1f1a3b87ef)
#02 pc 000000000018a608 /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#03 pc 0000000000160a2c /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#04 pc 0000000000162b6c /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (vrapi_SubmitFrame2+7564) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#05 pc 00000000048a85fc /data/app/myapp-Y6tT_vtGWj8JJ1PwgxheNA==/base.apk!libgrid.so (offset 0x6a9b000) (MyEngine::endVrFrame(unsigned int)+160) (BuildId: c9933f7ea0ad0c36a592bc4316e499e9db767d60)
The fact that the error is happening at an internal vkQueueSubmit() call makes me think that this is somehow related to the way I'm using command queues. But even if I set a separated queue as the synchronization queue and don't do anything with it (i.e., don't submit any command to it) I still get the same error.
Does anybody have an idea of what I could be doing wrong?
PS (1), I've tried to use a blank layer, instead of a proper projection layer, just to see if I could get past that point, but that didn't help.
PS (2), I'm getting no errors from the validation layer.
PS (3), the thread in which I enter VR mode is the same thread in which I'm calling vrapi_SubmitFrame2().
Let me start this by asking: who do you think would win, 18 years of experience in software development or this bad boi here '&'?
The mystery of SIGSEGV being raised from vrapi_SubmitFrame2() was nothing more than a stupid mistake when setting OVR's synchronization queue:
vpapi_DefaultModeParmsVulkan(&m_java, (long long)&queueHandle);
That line should have been written as:
vpapi_DefaultModeParmsVulkan(&m_java, (long long)queueHandle);
yesterday I got my "Ublox M8N Module". I bought it at ebay.
I connected it with Arduino Uno as USB to Serial Bridge.
I can change Baud rate to 115'200, disconnect in Ucenter and connect with 115'200. If I unplug the module from USB, the config is lost. Baud rate is 9'600 again. If I try to Update from 2.01 to 3.01 it doesn't work.
Battery Voltage is at 2.5V and it finds lots of fixes just in seconds.
Do you have any idea whats going wrong? How can I find out, if its a fake and what I have to do to make a fw update.
Here is the log from the fw updater:
Starting Flash Firmware Update
Loading and checking firmware image
Load FW binary 'C:\Users\User\Documents\GPS\M8N Firmware\UBX_M8_301_SPG.911f2b77b649eb90f4be14ce56717b49.bin'
Binary check success, G80 image valid.
Version: 3.01 (107900)
FLASH Base: 0x800000
FW Base: 0x800000
FW Start: 0x86C16D
FW End: 0x8808CC
FW Size: 0x808D4
Transfer Packetsize: 512
Transfer Packets: 1029
Checking communication link...
Communication link OK.
Identifying receiver updater version at 9600 baud.
Firmware loader version 5.01 detected.
Suitable Multi-ROM image found
Check pass: u-blox8 Multi-ROM image -> u-blox8 ROM2.01-receiver
Identifying Flash
Flash Detection timed out.
Done in 10.1 sec.
Statistics:
Erases sent: 0
Writes sent: 0
Erase timeouts: 0
Write timeouts: 0
This is the module:
http://abload.de/image.php?img=img_20170319_122602ccum3.jpg
Here is a Screenshot from the messages box:
http://abload.de/image.php?img=screenshotqhuli.png
I got the same mudule fron China. It's fake.
It's a module with a rom, not a flashram.
They put a new sticker on the module.
So, it's not possible to change settings.
I have a mediaplayer service inside my app . It can play Shoutcast Streams. I am selling my app to different customers who have different quality and formats of broadcast.
My own radio can be played without a problem which has the following properties:
Server Status: Stream is currently up but requires registration in the SHOUTcast Directory.
Listeners are allowed and the stream will act like it is private until resolved.
Stream Status: Stream is up at 96 kbps with 4 of 500 listeners
Listener Peak: 26
Average Listen Time: 27 minutes 2 seconds
Stream Name: **** Fm
Content Type: audio/mpeg
Stream Genre(s): Music
However, today I experienced a very interesting issue . One of my customers said the quality of the sound coming from the main speaker is too bad. I checked it on my phone and it really was bad. Interestingly , when you plug in a headset, the quality turns out to be how it should normally be. One more interesting thing is that the stream is played without a problem on tablets' speakers.
The customer's Shoutcast Server has the following properties:
Server Status: Stream is currently up and private
Stream Status: Stream is up at 96 kbps with 0 of 300 listeners
Stream Name:
Content Type: audio/mpeg
Stream Genre(s): Misc
What could be the source of the problem ? Is there a way to solve it?
What I want is for my iOS device to be advertising a Bluetooth LE service all the time, even when the app isn't running, so that I can have another iOS device scan for it and find it. I have followed Apple's backgrounding instructions here:
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/PerformingCommonPeripheralRoleTasks/PerformingCommonPeripheralRoleTasks.html#//apple_ref/doc/uid/TP40013257-CH4-SW1.
I can get it to advertise in the foreground ok and sometimes in the background but it doesn't stay advertising all the time. If you have it setup to run in the background, shouldn't it start advertising even after a device restart, just like background location services automatically start working after a restart? Are their limitations to the backgrounding that are not listed (or hard to find) in Apple's docs? Does anyone have an example of a Core Bluetooth Peripheral advertising correctly in the background?
Thanks...
Background advertisement is possible if you add the bluetooth-peripheral backgrounding mode to the app's plist. Once you do that, your app will continue to receive the callbacks even if backgrounded.
The advertisement is a tricky beast as Apple implemented several optimizations to reduce the power consumption and these reduce the quality of the advertisement as soon as the app is backgrounded. Namely: the rate is reduced severely, the advertised services are not included and the local name is not included either. Once the app comes back to foreground, these restrictions are invalidated.
In the general case, this kind of backgrounded operation requires the app to be running. With iOS 7 the restoration process has been implemented that allows the OS to act on the app's behalf while it is terminated and restore the app when some transmission or other operation is imminent. This requires you to add the restoration key to the initialization options of the CBPeripheralManager/CBCentralManager. Starting your application once is still required but after that, iOS will continue to act as the BLE facade towards the centrals/peripherals.
UPDATE: I ran a loop on the Apple bluetooth-dev list as well with this question and found that Core Bluetooth managers were declared to be not able to restore after reboot. This is not described in any documentation but probably was mentioned in the WWDC videos. We should file a bug and replicate it to raise Apple's awareness.
The implementation can be founded here:
https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/PerformingCommonPeripheralRoleTasks/PerformingCommonPeripheralRoleTasks.html#//apple_ref/doc/uid/TP40013257-CH4-SW5
Its very simply actually.
<CBPeripheralManagerDelegate>
#property (strong, nonatomic) CBPeripheralManager *peripheralManager;
...
- (NSDictionary*) advertiseNotBeacon {
CBUUID *myCustomServiceUUID = [CBUUID UUIDWithString:#"MY_UUID"];
CBMutableCharacteristic *myCharacteristic = [[CBMutableCharacteristic alloc] initWithType:myCustomServiceUUID
properties:CBCharacteristicPropertyRead | CBCharacteristicPropertyNotify
value:nil permissions:CBAttributePermissionsReadable];
CBMutableService *myService = [[CBMutableService alloc] initWithType:myCustomServiceUUID primary:YES];
myService.characteristics = #[myCharacteristic];
self.peripheralManager.delegate = self;
[self.peripheralManager addService:myService];
return #{CBAdvertisementDataServiceUUIDsKey : #[myService.UUID],
CBAdvertisementDataLocalNameKey: #"MY_NAME"
};
}
...
[self.peripheralManager startAdvertising:[self advertiseNotBeacon]];
Doing this, you will start advertising a peripheral service.
Now, if you want to keep the service running in background, read the documentation in this link: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1
Quick steps:
Open info.plist
Add a new par key/value
Required background modes
App shares data using CoreBluetooth
Apple says to ctrl + click on any key/value and add a add the following, but exactly the same as explained before.
UIBackgroundModes
bluetooth-peripheral
Dont forgot about the limitations of running the service in background:
The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.
If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral.
These changes help minimize radio usage and improve the battery life on your iOS device.
I've been researching this for a couple of days now and looks like it's not possible to keep bluetooth connection alive while the phone goes to sleep or if the app is in the background. However, I have found one app that claims they can run all the time: RunKeeper app says:
What's New In Version 2.5.1.0
Support for tracking heartrate in the background with Wahoo heartrate
monitor.
Does anyone know how they manage to send heart rate data to the phone while the app is in the background?
UPDATE:
Got it working by adding an entry in my plist under "Required background modes" for "bluetooth-central".
You need to use the new Bluetooth Low Energy feature via the CoreBluetooth Framework
Also note this is available currently only on iPhone4S since the Bluetooth Low Energy capability is dependent on the Bluetooth hardware in the iPhone.
In Xcode 5 there is a section for Background Modes in the your app's capabilities. Set Background Modes to ON and check "Uses Bluetooth LE accessories"