Chasing the MHz

Is it just me or is the smart-phone market actually going down the similar path as the PC market did a decade ago – chasing more cores and more Mega-Hertz speeds. Even while the smart-phone market is dominated by ARM-only platforms, it is still folly to be making hand-sets that are faster and furiouser than the rest.

I would think that these companies would have realised that it is far more important to improve the experience and functionality of the smart-phone than to increase the speed of the phone. Increasing the speed of a phone is easy – just wait a few months and Moore’s Law will ensure that it happens eventually. There is no magic in that.

I would think that the smart-phone is a booming market, that has still got so many pain-points. Although I must confess that I do not own a smart-phone, I am fairly familiar with their architectures and have a good idea of how to actually build one. The reason that I do not own one is because I do not see any useful phones out in the market.

If you were to just sit down and observe a smart-phone user, you will find that there are lots of problems with using the phone. For one, it’s terribly small and it requires a person to stare at the screen to use it. While I think that the touch interface is a pretty cool invention, I do not understand why it is that for a device that comes with a microphone and a speaker, I need to use my fingers and eyes to interact with it. To me, this is just silly.

If I was one of those smart-phone hand-set makers, I would put some good money into developing a new user experience that does not take my eyes off the road and fingers off the wheel. The first should be easy enough to accomplish. With gobs of memory and processing power, the phone should be able to speak to me instead of presenting a visual response. You don’t need to build some fancy text-to-speech engine to do this – just store MP3 samples of audio output.

As for getting user input, again, the system does not need to have some super speech-recognition engine built in. Just being able to discern a “yes” from a “no” can already build us a tremendously complex menu system. Then, put the money into the smarts of predicting what it is that the user wants to do based on context. If the user is driving, the user may be interested in accessing the GPS and *not* the camera application.

With that, we can probably come up with a better smart-phone – one that actually has some ‘smarts’ and is not dependent on my smarts.


Surround Microphone

I was watching Glee and a thought occurred to me. It was the final episode of Season 1 at the regional singing competition. Rachel and Finn walked down the aisles through the audience singing their parts. Then, I thought to myself what it would have been like to be seated in the audience and listening to them sing. That was when it occurred to me.

It would be cool if they had wireless microphones on that were location aware and that information was integrated into the sound system of the room. So, as Rachel walked down the left aisle onto the stage, the surround sound system in the auditorium would amplify their voices, but it would sound to everyone in the audience that the source of the voice was from exactly where Rachel was standing.

This should not be something too difficult to do. Let’s explore this idea a bit.

Most of the hardware complexity would be in the speakers and the software complexity would lie in the sound system. The trick would be to transmit a hidden signal within the actual audio transmission. This signal would be picked up by the microphone on the singer. Using some algorithm magic, we can estimate the position of the microphone in the room in relation to the position of the speakers. This can then be used to calibrate the voice stream received by the system to do its surround sound magic.

This has the advantage of being a cheap option. We can do this with present day equipment. This is the passive surround mic.

The hidden signal can either be embedded in the very low frequency or very high frequency range. Knowing how amplifiers work, it would be better to stick things in the lower frequency range. Then, to prevent picking up noise, we can borrow some ideas from infra-red transmitters – to not only transmit a signal but to transmit a digital signal over this low frequency. This allows checksumming and error correction to be done.

The resolution of such a system may not be too great, but it should be scores better than the overall ambient amplification we get today. The response time of the system may also not be that great. However, it will definitely be good enough to deal with most concert situations where people do not move faster than a speeding bullet.

To improve this all, we move onto the active surround mic. We will just need to equip the microphone with a wireless transceiver and mount a bunch of base stations on the speakers. The mic can then triangulate its own position relative to each base station using the strength of the wireless signal and also transmit its voice data to the nearest base stations over the same frequency.

C’est bonne idée, n’est pas?

PS: I’m not sure if such things are already in the market, I am not an audiophile – but they certainly should be!

Social Reader

I came up with this idea a while ago, while thinking about the whole e-reader craze. Since it will not be going to fruition, I thought that I would just write a blog entry about it. Maybe someone might find more use for it that me. Afterall, I lack the wherewithal to work on this project on my own anyway.

The idea that I came up with was a social reader. Yes, most of you will argue that reading is a very personal activity and wonder why anyone would want to have a social reader. However, there is at least one scenario where reading becomes a more social activity – in a classroom setting. So, this applies more to reading text-books rather than say Tom Clancy or Patricia Cornwell.

So, I had three ideas on how to use e-book readers in a more social way and I will talk about them here. Since this is a technical blog, I will elaborate mention some of the more technical aspects. Most of the modes elaborated depend on the modes supported by the 802.11a/b/g/n wireless chipset.

In the first case, the reader works in broadcast mode. This mode is suitable for use in a classroom where we have a lecturer broadcasting information to a bunch of students. In such a scenario, the reader used by the lecturer could be set in master mode and the students’ readers set to connect to it in infrastructure mode. In such a situation, wireless bandwidth is effectively shared between all the readers but since only one device is doing most of the talking, it should be fine. The reader application can then be programmed to transmit notes and synchronise meta-information to the students. This could be easily accomplished using rsync, or other system, in the background.

In the second case, the readers work in peer-to-peer mode. This mode is suited to discussion groups and small group teaching. In such a scenario, all readers are set to ad-hoc mode. This will allow each device to talk to every other device in the group. The reader can then be programmed to push or pull annotation between devices. In the background, a distributed management system such as git, or any other system, could be used to easily share data in a structured and managed way. the ability to do a diff and patch to your notes and that of your friends, could prove invaluable in changing how group study works in the future.

The third mode is a local-reader mode. This mode is suited to reading in the local common room. In such a scenario, readers can connect to a local book store that holds books only accessible from that geographical location – the boundaries of which can be controlled via modulating the transmit power of the book store device. Readers can download books held at the store and even upload books to the store, allowing people to share books and to leave books behind for others to read.

Now for the bad news – battery power. All these modes require the use of wifi, which is pretty power hungry. However, this is where there is opportunity for innovation. The operating system software could be designed to handle power efficiently and to only activate the wireless when needed – such as during the beacon intervals. Additionally, the physical layer could be replaced with something low-power such as blue-tooth or zig-bee or even possible uwb when it makes sense to do so.

In order for such a social reader device to succeed, it would need to answer the problem of power. Readers are supposed to be able to last days if not weeks. However, all the wireless communication will kill it quickly, even if low-power wireless technologies are employed.

Buffalo Ships DD-WRT

Looks like Buffalo is doing the right thing – shipping dd-wrt with its routers. While I have been a fairly loyal Buffalo customer and own several of their routers, honestly, I have been running all of them on dd-wrt. The only reason why I have been buying Buffalo is because they are the cheaper option to running dd-wrt than say, Linksys. So, by shipping dd-wrt on its routers, it will make life easier for me in the process.

DD-WRT is an Open Source project that provides firmware for running wireless routers. These firmware are based off a Linux kernel, which gives them a lot of power and functionality. For example, it can support VLANs, advanced firewall and routing capabilities and much more, on commodity hardware. Most of its features are available on premium commercial hardware.

I will not buy any router unless it supports dd-wrt. In Malaysia, this essentially limits my choices to Linksys and Buffalo. Buffalo wins on price because the features will be the same as long as they both run the same firmware. But why this obsession with running Linux dd-wrt on routers? It is all a question of control. I like having control over my hardware – including my routers.

For example, I configured my router to dynamically route all web traffic from my network via a transparent proxy server. This benefits all the machines running in my home network as I would not need to configure each machine individually. Everything is automagically cached in my proxy server. So, when I watch a YouTube clip, I can keep watching it again and again without having to reload it from the Internet. I also like the built-in PPPoE and dynamic DNS clients. I use it to maintain the connection to this very blog. Without it, you would not be able to find my blog at all.

If I did not have dd-wrt running on my router, trying to get these feature would be a chore, if it was at all possible.

The question then is why did Buffalo not do it from the start. I think that they have finally realised the advantages of using dd-wrt instead of building and maintaining their own firmware. You need a lot of resources to do that. It would be far easier for them to just customise a dd-wrt firmware with their logos and stuff while leaving all the hard work to the people who are actually passionate enough to work on it. In addition, they may want to consider hiring some permanent staff to contribute to the dd-wrt stack.

All in all, open source actually works better as long as people can change their mind-set on keeping everything to themselves.