|
|
Go to page [Previous] 1~2 | ||||||||||
jeffl Regular user 109 Posts |
Oh and the 3rd gen Apple TV puts out analog audio through its Toslink otherwise known as a digital optical cable, that's a pretty common interface but if all you have is an analog mixer you'll also need a D/A converter like FiiO TAISHAN-D03K-S/PDIF ($20) or better, which is readily available.
|
|||||||||
jeffl Regular user 109 Posts |
OK this is getting better especially on the iPhone side. Turns out if you're willing to use a desktop (that's connected to a wifi router of course) as your audio destination you don't need the Apple TV, if you have a Mac you can receive AirPlay by just installing a program called AirMac on it, and if you have a Windows PC you just get and install Shairport4W, you could just take the analog audio right off the rear panel connectors. Or if you want to send AirPlay audio to an iOS device like an Apple tablet you just open "settings" on that device and enable home sharing. And it looks like (I can't be totally certain at this point) you could connect a serious ECM lavalier mic like a Countryman by using the KVconnection adapter called KM-IPHONE-MIC-ECM for $24.50. So if you already own a reasonable iPhone that runs iOS 8 and ONE of these AirPlay "targets", that may be the only money you actually have to spend. (Yes I admit I tested the latency on the one Android phone I have and it was awful, not only that it wouldn't run Pokemon GO either [OK go ahead and laugh], just remember nothing ventured nothing gained!)
|
|||||||||
jeffl Regular user 109 Posts |
And if you just combine the AD-12 and CB-218 from All Electronics (use the yellow jack) you should wind up with the same connectivity as the adapter above for a fraction of the cost.
|
|||||||||
jeffl Regular user 109 Posts |
As far as apps for iOS to use your iPhone as a wireless mic, according to AppCrawlr there are two that are apparently worthy of consideration, there's iMegaphone for $2.99 which AppCrawlr gives a rating of 5.2 which does use AirPlay to receive the audio as I noted, and then there's AirMic for $1.99 which gets a rating of 7 but you don't use it with AirPlay, it still uses wifi but you have to use it with either a PC or Mac running a program called AudioReceiver which is available for free at www.mbpowertools.net for either platform. There are other apps available that do similar functions but either they don't use wifi or they don't operate in real time. (Air Microphone would be an exception but for some reason it only gets a rating of 1.5.)
Oh and I did a little evaluation while I was visiting a friend the other day, and while I don't recommend using the internal electret mic elements inside these phones for any professional purpose, on a purely technical level they actually have quite a flat frequency response (with maybe a little low-end rolloff in the circuitry for wind issues). It turns out the reason many of these mics exhibit a significant "presence peak" is they're coupled to an air chamber inside the phone that's approximately the width of the phone. So when the sound goes through the air slot it is effectively coupling through a Helmholtz resonator with a peak at a few kilohertz so there's your presence peak. I don't know whether the designers do that intentionally but that's why you see that peak if you try using an audio real-time analyzer app on the phone. At this point in time I'm not very optimistic about the possibilities for using Android given that you'd have to use a high-end late model Samsung like a Galaxy S6 or S7 and a low-latency app written specifically for those phones like Soundcamp. I don't know about you, these are fine phones but I don't think it would make sense to buy one just for a mic, and I CERTAINLY won't be buying one anytime soon JUST to see if it works with very low latency as advertised! I guess I'm a little embarrassed that I didn't know that inherent in the Dalvik VM used in Android up to 4.4 (and even in the Android RunTime that followed it) was a source of all that maddening latency, I still don't know why they couldn't provide a mechanism for doing an "end run" around all that and just letting the app set a flag that DOESN'T go through the VM if you wanted to just route audio through to the wifi and you weren't interested in doing processing in the app itself but oh well. In fact I don't plan to even buy a used iPhone before the end of the month so it may take a little while before I can report firsthand on this (I'm kind of busy in the short term anyway), maybe since I've done most of the "heavy lifting" here there might be someone else "of a geekish nature" here who could perform some tests on their own gear and report, but I need to emphasize that in the long run it's really mostly quantitative results that actually matter. |
|||||||||
jeffl Regular user 109 Posts |
And I forgot to mention, if you are intent on going the Samsung/Android route and you want to or can use a PC as your audio target, apparently there exists a freeware program called foobar2000 will allow the PC to receive audio via DLNA, although I'm told by reviewers that the program "can be a bit difficult to get working" for this purpose but I don't know much more than that.
|
|||||||||
jeffl Regular user 109 Posts |
So I haven't posted on this topic in over 5 months, I suppose folks either assumed that I had lost interest or given up or something, actually I've been doing quite a bit of "applied research" on the topic, I would certainly have to say that there was a lot to learn, you will recall that when I first posted I had never even owned a smartphone, but as I originally "confessed" I tend to approach new topics from a standpoint of substantial optimism (and I doubt anyone would condemn me for taking such a standpoint if indeed I'm attempting to discover solutions rather than excuses), and like I said with the proliferation of digital radio capabilities and programmable interfaces (through the mechanism of "apps" or short ptograms) that a smartphone provides it seemed at the time that all one needed to do was to survey the available possibilities and select the best from whatever worked. Well now I own both an Android phone AND an iPhone, and I've come to realize that the confluence of short development schedules, competitive market forces and just plain corporate greed have conspired to squander these opportunities to the point that if there are any "really good" opportunities to use digital radios for real-time audio they remain pretty darn obscure even to me, although I have clearly identified a number of alternatives to the kind of "proprietary radio" analog technology that one sees in "pro audio" stores all the time. More importantly I want to disclose what I've discovered are the primary roadblocks so others attempting to make the same journey need not traverse the same roads because it is a giant time sink that hopefully my study will make quite unnecessary.
Let me start by explaining a bit about how Wi-fi works because the source of latency there is a bit obscure. When we take a Wi-fi router and refer to it as "N750" or "AC1200" what does that mean? It turns out the letter refers to the level of IEEE 802.11 that the router is "compliant with" and the number is the AGGREGATE level of megabits per second that the router is capable of sending to or from the internet connection at one time. It turns out that for the most common configurations the maximum rate available to any single router destination is around 150 megabits per second. If you "do the math" you can quickly compute that the bit rate required to support a single mono audio channel at the standard CD sampling rate is only around 700 kbits/second, it certainly sounds as if the available channel bit rate is fast enough to support continuous transmission, especially if the microphone is the only data being sent at the time! (For reference the reason I'm discussing data rates in the context of a router is that in general smartphones do not support so-called Wi-fi "ad-hoc" or routerless connections, although in other contexts that would certainly be a possibility.) But if you connect a smartphone to a PC through a Wi-fi router and you perform a simple "ping" test from the PC back to the smartphone, you will see that the link delay for a default 32 byte packet frequently creeps up to 200 milliseconds OR MORE (and I should state that I would assume that useful packet lengths for continuous audio transmission would be much longer). What the heck is going on?? Well when I saw this I of course figured that the delay could be due to programmatic delays induced by the router itself, and at the time there was quite a bit being written about projects in the field of open-source firmware. Now this field originally developed because network routers are basically small embedded computers made in huge quantities at fairly low margins and a wide variety of models, and users had observed that many times the firmware in those routers that they had in their homes or at work had substantial security flaws in them, and there was not enough operating margin left for the manufacturers to be able to afford major development programs to track these errors down and issue corrected versions for all these models for download, so a creative and resourceful community arose to resolve these issues AT LEAST for themselves, and ultimately for the aftermarket router community. So these folks had identified a source of router latency they called "bufferbloat" and at least one of them (OpenWrt) was issuing builds incorporating alternate strategies for router packet buffer management (one that was particularly interesting is known as "fq_codel"), so I endeavored to find the corrected version of software for my make and model of router, download and install it and once again all would be right with the world, would it not? Well I won't spoil the ending just yet (although the entire premise for the latency turned out to be incorrect), but the whole concept of replacing the firmware in your router can be JUST A LITTLE BIT more complex than you might at first believe. The first issue is for this to work your router hardware has to be "of the correct vintage" (mine was unfortunately too new), if it's too new then they MIGHT "release" some code that hasn't been completely tested and doesn't actually work AT ALL (which happened to me of course), if you find a version of code that's been thoroughly tested and it's for an older model then you may find that model has been discontinued and you may have trouble buying it for an affordable price. So there's a "time window" that you have to cross-reference against a table of models for which code is currently available, supported for the latest release and vouched for as working...and this is all just to get a testbed to look at...! And if you load firmware on a router and you DON'T get your "GUI" (graphical user interface, like your "Windows" controls) working immediately, then you have to consider whether your "power-on reset" gives you a mode where you can restore you factory default code and at least succeed in not breaking anything. Then again if THAT doesn't work you might have to learn about a mechanism called "TFTP recovery", and if THAT isn't successful you might have to crack the router open physically and "wire into" the "hidden serial port" (provided in almost all modern routers) and purchase a special USB/serial adapter, and...well, I'll spare you the bloodiest of the bloody details, but two router purchases and a WHOLE LOT of blog interaction later, and I finally arrived at the ultimate truth, which is... OK it turns out that the entire "bufferbloat issue" is ONLY about routing packets to and from the devices to and from the cable or DSL modem (WAN port) and the individual devices (LAN ports) which are "separate interfaces". If you're talking about devices like smartphone Wi-fi devices well they're "operating on the same interface" (as far as the router is concerned) and the delay from one to the other is, well, ZERO! Say wha'? (If nothing else this goes quite a long way to explaining why every network engineer I approached this problem with "looked at me like I had three heads" at least figuratively speaking!) Uh, OK, then I'm back to my original question, where the heck is all this latency coming from? And that's when I came upon the "dirty litle secret" of Wi-fi networking: the entire system was concocted to "disguise" the fact that retries were being performed, and just HIDE IT IN INCREASED LATENCY! And even worse, while I recall back in school I learned about simple and cheap ways to perform not just error DETECTION but also CORRECTION on a channel at the cost of some information redundancy and modest complexity, the Wi-fi standard specifies NONE OF THAT (turns out there's quite a bit though in the specs of how CDs, DVDs etc. are recorded). In other words the WHOLE ISSUE OF MESSAGE TIME DETERMINISM IN THE WI-FI SPEC IS JUST THROWN INTO THE GUTTER. Worse many of the design decisions made in the code of the drivers for these devices are being made by folks with absolutely no knowledge of the proper way to figure out the tradeoffs. In fact this situation has gone so far beyond a tolerable level that the folks who initiated the whole "bufferbloat" discussion have an entire project and several webpages called "Make Wi-fi fast". Well so much for Wi-fi, what about Bluetooth, does it have a similar delay issue? (I guess the most "modern" version better not, if there were several milliseconds differential between the two Airpods being communicated with by the latest iPhone 7, what would happen to the stereo image would be VERY interesting!) Uh the exact situation with it is quite a bit more "opaque" because Bluetooth doesn't really offer tools like "ping" to evaluate latency issues. It turns out the protocol is A LITTLE less prone to specific issues of latency because transmission is basically intended to occur mostly between only two "paired" devices (although NOT exclusively, in the newer versions of this protocol these "health monitor" watchbands and such are specifically designed to send data to UNPAIRED devices but neither latency nor receipt of a particular message intact is considered essential). I have however seen documentation that purports to show that Bluetooth latency under about 35 milliseconds is generally pretty much a "safe bet". Now in the case of Apple, many of the standard "higher level" protocols like AirPlay (for media streaming) and AirDrop (for file transfer) require that BOTH Wi-fi and Bluetooth "transport protocols" be working and available, but we definitely AREN'T safe in assuming that iOS will automatically select the method with the shortest latency for any given transfer...! But it turns out that exactly BECAUSE Wi-fi latency is so unpredictable, the specification for AirPlay actually stipulates that the devices sending data must be capable of buffering TWO FULL SECONDS of (video + audio) data in order to be compliant...gee that's NOT exactly real-time transmission, is it? And if we "look around" at competing arrangements, some folks are reporting that what I used to call Chromecast (I think it's called something else now, what time is it?) "mandated" buffer latency has been observed running as high as 4 or 5 seconds!! The only other "high level protocol" that one typically encounters for media would be DLNA (I suppose there may be others) but I haven't seen any apps written that are compliant with it, if that's even possible. So maybe we still have hopes for "raw" Bluetooth you might think? Well it turns out the problem with it isn't latency, it's connectivity. I can't say for sure but it's just possible part of this arises from the way the protocol "stack" software is written and deployed. You see the "stack" in the iPhone is Blue Magic 3.0, Android uses BlueDroid. A Windows PC might use the default stack from Microsoft (only if you got the PC in OEM distribution with a Bluetooth dongle installed, unlikely but I suppose possible), if you bought an "aftermarket" dongle the stack could be from Broadcom/Widcomm or Qualcomm/CSR (used to be Cambridge Software Radio) or even Toshiba. So when I took my PC and iPhone and Android phone I couldn't get any two devices to "pair" with each other. Then if you call any "stack vendor" for support you get the "song and dance" that "oh WE got the protocol right, it's THE OTHER OUTFIT that failed". (That's if you can even succeed in getting them to issue a support ticket #, in my case CSR wouldn't even acknowledge that I filed a complaint!) Plus I've learned in the case of Apple they tend to be VERY "cagey" about exactly WHICH kind of "device connectivity" they even permit to occur because if they determine that another type of connection is desired they MIGHT have just discovered a new product they could sell. I suppose if you COULD get an iPhone to pair with an aftermarket Bluetooth receiver at about $15 (bypassing AirPlay and its 2s delay) you MIGHT have a workable "link" but I don't think I'd hold my breath until you found it!! (Again we're talking about the iPhone because its inherent latency is about 9 msec, you could maybe get close to that with Android with a Nexus 5X or 6P or Pixel but those phones are out of my price range, you might be in a different situation.) By the way the hardware inside the iPhone is considered to be an "SDR" or software defined radio. There's a rumor going around that inside the iPhone "internals" there's enough resources to make a completely functional FM stereo broadcast receiver (apparently in other countries especially in Europe that feature is fairly common in competing phones so Apple decided to have it there for potential competitive reasons). There's an even MORE interesting rumor that if they wanted to they could make a perfectly decent short-range FM stereo transmitter! If they did THAT they could instantly "wipe out" the incessant market of FM transmitter "dongles" that are sold for the benefit of people who want to play their music collection over the FM radio (and speakers) in their car (although curiously they're seldom sold with the proper adapter to take audio directly off the headphone jack of a smartphone). Since these are virtually "ubiquitous" and for sale almost anywhere you would expect to find electronics for sale, I can't help but mention that (although this doesn't "meet any kind of professional performance standard") it certainly COULD be possible to use something like this with a smartphone for a low-latency arrangement of sorts (on most of the ones I've seen even though it's an analog signal the modulator chip is digital therefore fairly deterministic). Generally for about $5 you get your choice of 3 or 4 carrier frequencies, for more like $10 you get a display and you can pick any frequency you want. If it were me I'd find one where I could identify the pin on the chip that puts it into stereo mode and disable THAT to get mono only (that ought to give 10-15 db more to the signal therefore much better range), there's even an "instructables" that purports to explain how to bypass the "transmit power limit resistor" on one of these which of course renders the entire exercise illegal by FCC standards - but who's counting? So have I presented a "definitive" solution? No I haven't. Then again I haven't ruled out the possibility. Maybe though I've at least made it easier for somebody else to find one, or at least saved them from wasting time investigating the same thankless issues! (And I hope I haven't just created one of the longest TL;DRs you've ever seen!) |
|||||||||
Ray Pierce Inner circle Los Angeles, CA 2607 Posts |
Max Maven once opined, "It is theoretically possible to cut a piece of steak with the sewing machine, but why do that when we have knives?" All of your research and work is really interesting on a purely academic level. As a sound designer, mixer and performer, I'll probably be staying with my industry standard wireless mics.
Ray Pierce
|
|||||||||
The Magic Cafe Forum Index » » F/X » » Use your smartphone as a wireless mic (4 Likes) | ||||||||||
Go to page [Previous] 1~2 |
[ Top of Page ] |
All content & postings Copyright © 2001-2024 Steve Brooks. All Rights Reserved. This page was created in 0.09 seconds requiring 5 database queries. |
The views and comments expressed on The Magic Café are not necessarily those of The Magic Café, Steve Brooks, or Steve Brooks Magic. > Privacy Statement < |