I try to use DeepSpeech for call center, to dictate and summary conversation.
In this scenario, there are always more than one speaker, usually two speakers. Is there any way to distinguish the speakers while DeepSpeech is recognizing the conversation?
Thanks for your advice.
Jin.
Related
I've seen a lot of projects, tutorials and how-to's on the web regarding the Raspberry Pi.
I've just received my first Pi in the mail, and I can't wait to get tinkering with it.
Of course, doing any of these things is going to be a difficult process, however, as my experience with the Pi is next to none, I wondered about the capabilities of what I want to do with my first major project.
I'd like to be able to build an on-board computer for my car. I've seen several projects regarding this, and I've seen some good guides online.
However, none that I have seen will do EVERYTHING that I can think of....
I'm assuming that my 8GB SD card will be limited to only a selection of these specifications, however, here's a list of what I'd like the solution to be capable of, and if anyone knows any reason why this isn't possible, please give me a heads up :)
So...
I'd like a front-end GUI (on a 7" touchscreen monitor) with a menu to navigate the options, which will include
From this menu, I'd like to be able to select (and of course, run) the following:
Media center (I've seen things like XBMC etc.) - I'd like this to be capable of taking over the radio unit and playign mp3's etc (possibly from my iphone!?)
GPS/SatNav - I don't know how possible this is and I assume i'd need a 3G card or something...
Reverse parking camera (stick a webcam in the rear view window) etc (I've seen good tutorials for this)
Connect my phone with a bluetooth thingy(?) so that I can add a USB mic and play the receiver audio through my speakers (acting as a hands free kit)
I'll add more ideas too...
I'm not questioning if each of these individual specifications are possible, I am asking if they are all possible through one solution as a whole, with a GUI to navigate through them?
Thanks for any help.
Cal.
It is all possible, all in one bundle. 8gb is more than enough for everything, it'll only limit your music collection. The only question is: how much work are you able/capable of doing. That will be the limiting factor, not your Pi.
Short answer is yes, all exist and the pi can handle it. But you'll be writing a lot of custom software to make them interoperate.
I'm looking to connect my iPhone to an RS-232 serial device via Bluetooth. Has anyone implemented this successfully and can offer advice on hardware to use? It's kind of tricky because of the need for the Apple Authentication Processor with the device. The best potential device I've found is this guy but it only comes in an embedded package, its serial port interface is just logic-level UART rather than line-level RS-232, and I can't find a supplier with it in stock.
Any thoughts would be appreciated.
I'm considering just using WiFi to serial instead, but please ignore that possibility for the purposes of this question.
most of the question was answered by yourself already.
Basically you have 5 (+2) choices.
Join the MFi program. This might be hard to impossible if you are not part of a at least mid-size company.
Buy the OEM Bluetooth Module. I'm not sure if this is even allowed by the apple policies.
Use WiFi. Keep in mind that you want to use a wifi chipset that can act as at least ad-hoc access point. Those chipsets are quite expensive, and you have to think of a way to join existing networks (customers don't want to leave their home network to use your product). This will add a lot of cost to the BOM of your device.
Jailbreak might be an option. I never tried to use accessories with a jailbreak, so I don't know if it's possible to use bluetooth without authentication.
Work with a company that is member of the MFi program.
(Maybe an option, and depending of the speed you want to have via RS232: Eventually you can convert the audio output of the head-phone jack to RS232 levels and vice versa)
(Not really an option: develop for Android and do whatever you want)
If you jailbreak your device, you can use BTstack.org (disclaimer: I'm the author of BTstack) to connect to a Bluetooth device that supports the Serial Port Profile. You can get Bluetooth Modules that implement SPP and provide UART level output. As David R. above points out, you then need a UART to RS232 converter, e.g. the MAX232.
Ok. Another option. There are one or two companies that sell RS232 cables for iOS, eg. Skywire here: http://www.southernstars.com/products/skywire/index.html
Then, you could uses a Bluetooth RS232 extender, which consists of a RS232-to-SPP and a SPP-to-RS232 pair. Ugly, but within Apple's rules.
Well. It seems like my answer could be something you didnt ask for.
But the guy you referred to is the answer. Buy his product and you are good to go, all you need is a MAX232 chip. Converts logic level UART to RS232.
the diffrence high + voltage low zero voltage is converted to high +~10volts low -~10volts.
I use the MAX232 chip with my microprocessor, that uses logic level USART to communicate over RS232.
There is a lot of tutorials out there explaining how to hook things up.
This product works: https://serialio.com/product/bluetooth-serial-adapter/bluesnap-smart-bluetooth-40-ble-rs232-adapter
The only downside is that the adapter requires power.
It should be possibly I would think to create something in the middle that accept the bluetooth commands and convert them to serial, similar to what this does with TCP connections: https://www.npmjs.com/package/stellar-socks
Is it possible to detect and respond to the answer/end-call button presses from an HFP Bluetooth device on iOS? Has anyone seen this? Where should I look for answers? I understand one could get access to lower level bluetooth if you register for the device manufacturer (MFI) program but I'm hoping I don't have to dive this deep. I also know that you can respond to AVRCP commands but I am not wanting to use this option. Can anyone help?
UIResponder has a -remoteControlReceivedWithEvent: method that you can use to receive events from external devices, possibly including Bluetooth headsets. From the docs:
Remote-control events originate as commands from external accessories, including headsets. An application responds to these commands by controlling audio or video media presented to the user. The receiving responder object should examine the subtype of event to determine the intended command—for example, play (UIEventSubtypeRemoteControlPlay)—and then proceed accordingly.
To allow delivery of remote-control events, you must call the beginReceivingRemoteControlEvents method of UIApplication; to turn off delivery of remote-control events, call endReceivingRemoteControlEvents.
It’s not clear whether the answer/end button on a headset is considered equivalent to the play/pause button on, say, the earbuds’ remote, but this might be worth a try.
Sadly, there are no available bluetooth public APIs for developers, so no way to get that access in the conventional means.
As of my research, some person received some event from their bleu-tooth devices via "remoteControlReceivedWithEvent" but not all of them! Some are receiving none! And very few are receiving all of them!
I also tried Core Bluetooth but it only supports LEB (Low Energy Bluetooth devices)!
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothOverview/CoreBluetoothOverview.html#//apple_ref/doc/uid/TP40013257-CH2-SW1
Also, some posts suggest it is possible to use Classic bleutooth instead of "Low Energy":
How to use bluetooth classic instead of le
But it has limitation as well (the post is taking about "MFi accessory"! MFi is it for "made for iphone" ?!?!?!)
from the post above:
"A non-LE Bluetooth device needs to be MFi-approved to be used with the External Accessory framework (it needs to use a specific Apple chip and a proprietary communication protocol). You won't be able to build applications to access this device unless it either uses the more open Bluetooth LE or has this chip in it for standard Bluetooth. There might be ways to do this via jailbreak, but pretty much everyone I know has moved over to Bluetooth LE." !
more post: Connecting to a Bluetooth device from iOS, no MFi
Regards.
Intro: I have a Denon S-52 internet radio with an iPod/iPhone dock (the older 12V kind, so charging is not possible with newer devices but audio/control data is passed through). The radio has an external clickwheel-like control that worked beautifully with iPod nano/classic etc. Since the iPhone/iPod touch no longer have any clickwheel functionality, the signals from the Denon clickwheel no longer have any effect while playing (ie no seeking), but can navigate through some menus on iOS, and play/pause works. The few clickwheel apps I've tried obviously ignore the external signals.
Questions: How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)? I'm assuming this is possible because the signals are sometimes processed (as mentioned above), but I'd be happy to be proven wrong before I waste a lot of time and effort. I also assume a standard $99 iOS developer membership would be enough (since the device itself is already MFi)? Or perhaps an app that has this feature already exists?
How hard would it be for someone with no iOs programming experience (just C/C++/C#, plus an objective C tutorial from lynda.com) to develop a basic audio player app that would accept signals from the external Denon clickwheel to seek within an audio file (for my own use, at least at first)?
Nearly impossible. It's not just the challenge of figuring out how to access the dock connector and interpret the signals of interest. The real problem is that you want to use those signals to control music that's playing, and you're probably thinking of trying to control the iPod application rather than writing your own music player. Communicating between two apps is difficult at best, and probably not possible if the target app (iPod) doesn't provide a mechanism for external control. And the fact that you're new to the platform doesn't make any of this easier.
Your best hope is probably to file a bug with Apple requesting this feature and hope that they'll add it for you.
I was able to do this by jailbreaking my iOS device, which enabled me to access the serial port for iPod Access Protocol communication at /dev/tty.iap. Then I could incorporate something like the functions found in this iPhone Serial Port Tutorial (check archive.org if the link no longer works) to read the incoming signals and respond accordingly.
Update: An even better solution seems to be to write a tweak hooking into the iPodUI private framework and intercept the commands directly, and then message the Music player about what to do (see this post for more details).
Experts, I want to develop an app (with accompanying hardware) that turns 2 leds (Light Emitting Diodes), in different frequencies, I found this pin out for the iphone/ipad connector
link.
The questions are:
what pin should be the best to accomplish my flickering led? pin#? and and (GND off course),
what function in objective C will allow me to do this?,
I found this site for buying the connectors, do you have a better one?
I intend to have the earphones connected as well, so the sound pins are not an option,
thank you in advance!
edit>
here an example of an
external flash light for the iphone
light
so I ask you guys please the same question, what pin and what function is used to turn this light on?, I can take care of the frequencie generation and the electronics, thanks!
The ExternalAccessory.framework is the best place to start. It's covered in the External Accessory Programming Topics.
Manufacturers must build explicit
support into their accessory hardware
for communicating with iOS. As part of
this support, an accessory must
support at least one command protocol,
which is a custom scheme for sending
data back and forth between the
accessory and an attached application.
Apple does not maintain a registry of
protocols; it is up to the
manufacturer to decide which protocols
to support and whether to use custom
protocols or standard protocols
supported by other manufacturers.
It's basically all up to you to create the protocol but the ExternalAccessory.framework is where iOS meets the external device.
Original answer, which would sound snarky to an electronics engineer, removed. :-)