Friday, 12 February 2010

川湯温泉




I spent last weekend at a curious place I'd heard stories about since I first came to Japan. Its an area of Wakayama prefecture where warm, volcanic rock runs underneath the riverbed in such a way that you can literally dig you own onsen (hot bath). Being the middle of winter and all, it was pretty damn cold outside so our digging efforts were soon abandoned in favour of the pre-dug pool 200 metres down river from where we were staying but I can vouch for the fact that there were indeed puffs of gas rising from the shallow rocky river directly outside our hotel window.

The hotel we stayed at (木の国温泉) - a traditional ryokan - was quite old but the food and price were nothing short of incredible. Freshwater fish, nabe, sashimi, gratin, miso soup, ... a banquet fit for kings. For anyone looking for an escape from busy Osaka life and something a bit different, this place is definitely worth considering.


Wednesday, 3 February 2010

The state of sound in Win32

To flesh out my video-conferencing related posts I guess its only fair I have one on sound as well. Windows sound systems to be precise. As I've recently learned, there are *5* different systems that deserve a mention.

Windows Multimedia Extensions (WMME)

This has existed since the dawn of time (Win3.1) and provides a nice fail safe API for sound output. It generally only works for one device at a time unless its emulated (the case for WinXP and up).  The latency you get when using this API makes it completely impractical for video conferencing use.

DirectSound

This used to be part of DirectX and is now part of the platform API (DirectShow?). Apparently provides latency down to around 50ms. On Vista I have seen Speaker-to-Mic sampling latencies range from 60ms to 220ms.

WDM Kernel Streaming (WDMKS)

This API provided the closest access to "bare metal" as possible until Windows Vista. WDM KS gives much better latency than WMME and DirectSound but it generally means opening a device for exclusive access and since you can't steal access to a device from another running application. I don't believe the average user understands the concept that a paused You Tube video is still using their sound device so this API is written off for practical reasons.

ASIO

Steinberg created this API to provide low latency access to audio for professional applications. It solves the latency issues but requires ASIO drivers which only high-end cards seem to have. There is a project called ASIO4ALL but it achieves ASIO support on regular devices through use of the WDM KS API, thus making it no better than accessing WDM KS directly.

WASAPI

This was added in Vista and seems to be the best sound API that Microsoft have come up with. WASAPI internally uses 32 bit floating point samples at a fixed sample rate (determined by the device drivers. typically 48khz). Mixing is done by the OS and tracked per application. In the general case, under Vista and Windows 7, this is the only API that directly accesses the hardware. This might not be the case if using legacy drivers but seems to be true of all systems I've tested audio code on.  Implementation of the other sound API's are emulated and running on top of WASAPI.

(Need to check this is the case for WDM KS.. It may run either/or with WASAPI.)