Re: [Jack-Devel] JACK2 for Android newly released!

PrevNext  Index
DateWed, 29 Jan 2014 00:36:15 +1100
From Patrick Shirkey <[hidden] at boosthardware dot com>
ToJack devel <[hidden] at lists dot jackaudio dot org>
In-Reply-To김정연 Re: [Jack-Devel] JACK2 for Android newly released!
On Wed, January 29, 2014 12:23 am, ±èÁ€¿¬ wrote:
> 2014. 1. 28. ¿ÀÀü 12:59¿¡ "Christian Schoenebeck"
> <[hidden]>ŽÔÀÌ
> ÀÛŒº:
>>
>> On Saturday 25 January 2014 14:55:11 ±èÁ€¿¬ wrote:
>> > > First, the framework only supported I/O via built-in audio devices.
>> No
>> > > USB. This means audio quality is compromised by their audio
>> hardware.
>> > > Importantly, they are restricted to 48k/16 bit.
>> >
>> > Yes, it is true, but most of things are platform dependent. Not a jack
>> > domain.
>>
>> What do you mean with "platform dependent"? External USB audio devices
> usually
>> support the "USB audio class" standard protocol nowadays. Support for
>> such
>> devices is provided by a standard Linux kernel module which is platform
>> independent.
> Yes. android officially support USB Audio by framework level.
> But, how to JACK access and use /dev/usb/... as audio device using jack
> driver?
> I have no background about that.
> Are there any bridge between usb~alsa?
>


Can you use the usb-audio module?

modprobe snd-usb-audio

You may need to recompile alsa or the kernel with that module enabled if
it is not already present.




>>
>> > I think these XRUNS related cpufreq on demand governor when a jack
> client
>> > runs during low CPU frequency mode in mobile device. Please refer:
>> >
> http://bamboopuppy.com/android-cpu-frequency-using-cpufreq-ondemand-governo
>> > r/ As I know, there were already discussion in here, so I found
>> Robin's
>> > jackfreqd, How do you think for solution?
>> > http://rg42.org/oss/jackfreqd/start
>>
>> Yes, CPU scaling (CPUFreq) is one of the major reasons for xruns. You
> could
>> first try whether this is the case by:
>>
>>         cpufreq-set -r -g performance
>>
>> to find out whether that is sufficient to solve the xruns. That would
>> set
> the
>> CPU cores to maximum performance. If that looks well, you could then go
> ahead
>> with a production solution like i.e. jackfreqd or something based on
>> that
> idea
>> to both save power whenever possible and not having xruns in audio
>> performances.
> Ok. Thanks.
>
>>
>> > >> > What about low latency/RT stabilty, have you tested running JACK2
> with
>> > >> > low latency period settings (i.e. <= 5ms) on Android? Does it run
>> > >> > quite stable without xruns?
>> > >>
>> > >> Well, it is hard to say, latency depends on platform limitation or
>> hw
>> > >> spec. for example, android's fast mixer introduces 10ms of latency.
>> > >> http://source.android.com/devices/latency_design.html
>> > >>
>> > >> Generally, mobile devices do control power consumption much
>> sensitive
>> > >> than PC, of course this limitation may possible occur XRUNS in some
>> > >> scenarios.
>> > >> We always think how to improve performance better, *** so I need
>> > >> expert's advice here. ***
>> > >> But, modern mobile devices increase number of cores(quad-core or
>> > >> more...), so I guess JACK2 works better performance along with
>> number
>> > >> of cores. Of course, it works stable if allows reasonable
>> clock-speed
>> > >> and cores.
>>
>> I don't know what kind of hardware components you are using exactly, but
>> I
>> somehow doubt that latency issues are caused by your hardware. iOS
>> devices
>> deliver rock solid low latency from day one (for more than 6 years now).
> And
>> there are various other ARM based hardware on the market which also
> deliver
>> reliable low latency if being equipped with the right OS & co.
>>
>> Are you running a hypervisor kernel like OKL4 on lowest level and
>> Android/Linux on top of it? Or is the Android/Linux kernel running
> directly on
>> the ARM CPU?
> I have no idea about hypervisor or something.
>
>>
>> Best regards,
>> Christian Schoenebeck
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>


--
Patrick Shirkey
Boost Hardware Ltd
PrevNext  Index

1390916111.22852_0.ltw:2, <54052.86.105.95.182.1390916175.squirrel at boosthardware dot com>