Active Topics

 


Reply
Thread Tools
Addison's Avatar
Posts: 3,811 | Thanked: 1,151 times | Joined on Oct 2007 @ East Lansing, MI
#51
I'm quite behind in this thread, sorry.... But is someone finally considering a port of Audacity?
 
Posts: 72 | Thanked: 184 times | Joined on Apr 2011 @ Germany
#52
Originally Posted by Estel View Post
Wait, wait - audacity records from alsa external USB soundcard without problems in ED? I must have missed it. It's great news!

I wonder if totemplayer (with leetnoob's hacks to enable accelerated playback in it) in ED can easily use external sound card. Will try to check that, as time permits (not to much time those days, hardly enough to keep in pace with TMO and great ideas like that).

/Estel
I was writing about it in the hostmode thread (my second post I think), recording worked in ED with Audacity, attempts to playback crashed the device. But performance is rather sluggish, maybe this can be improved by recording to sdcard to avoid I/O conflicts with swap, or other settings in Audacity.
 

The Following User Says Thank You to Oblomow For This Useful Post:
fpp's Avatar
Posts: 2,853 | Thanked: 968 times | Joined on Nov 2005
#53
Originally Posted by Estel View Post
Finally I got time to unplug all cables from my desktop, and test Audigy 2ZS Video Editor with N900 - fpp was right, in fact it works as audio device (+ 4 port, powered USB 2.0 HUB, that is bundled inside), leaving only video capabilities for proprietary drivers = inaccessible.
Hehe... told you so... :-)

smplayer is great mplayer front-end available from repositories. Of course, as it's still mplayer, it doesn't allow to use DSP assist in decoding... Yet, its using GUI and settings, to allow doing every thing that you can do with mplayer via terminal (at least, things that I'm aware of), adding to it every function that You would expect from GUI media player, like manipulating playlists, normalizing volume etc.
it's no different when it comes to selecting output audio device - I was able to choose my USB sound card via GUI drop-down list. Fortunately, no one decided that this option should be cut off while porting to Maemo "as no one could ever use it at the time of porting [it seems to me, that it was ported before hostmode become available]" - kudos for original creator/porting dev.
Yet another great Maemo package I was unaware of... thanks for the tip, I'm trying it out !

Furthermore, in my case it uses exact same amount of CPU time to decode, as when using N900's internal DAC. To be precise - mplayer process itself uses more CPU with external DAC, yet, with internal DAC, CPU cycles are "divided" between mplayer and pulseaudio. I've tested many times, and result were the same - 60-61% @500 mhz when decoding Q=6, VBR, lowpass=20kHz ogg file. At first, this part of my findings seems to be opposite to Oblomow research, yet, I'm not sure if "dividing" CPU cycles between mplayer and pulseaudio (when using internal DAC) was considered there (?).
Interesting find... although of course it just means that if we could use the DSP *and* bypass PA, then we would use even *less* CPU cycles that the stock media player :-)
Also, CPU decoding is very dependent on the codec type and its settings : flac, mp3 and ogg will have different CPU usage patterns for example. And also flac 0 vs. flac 8, or mp3 128k vs. mp3 320 vs.mp3 VBR0, etc
I wonder (but this is just a wild guess) if DSP decoding would prove less variable.
__________________
maemo blog

Last edited by fpp; 2012-04-02 at 19:22.
 

The Following User Says Thank You to fpp For This Useful Post:
fpp's Avatar
Posts: 2,853 | Thanked: 968 times | Joined on Nov 2005
#54
Originally Posted by jerryfreak View Post
for some background on similar application, many of us have been recording 24-bit 96khz spdif with dell axims for almost a decade using a PDAudio compact flash card audio interface. ive used this same card to record to a $200 old notebook with a cfcard/pcmcia adapter and alsa drivers with ecasound command line. this was before the dawn of decent USB audio solutions, of which there are now many...
You are very right, the sad truth of the story is that there is nothing new at all here.

Ten years ago, the iRiver H1x0 had an optical spdif out (which could even be hacked into coax), and audiophiles were using them with their DACs.

Right as we speak, some Gen9 Archos tablets have an USB Host port and a modified Linux kernel that lets them play music to an external DAC. They are otherwise uninteresting as tablets go, and not very portable, but Archos made them more capable (probably quite easily) than all other Android devices.

So this is very well known and basic technology, and not even costly to implement. It's just that there is no market interest because the user base is so small (although if Apple were to "invent" the iDAC I'm sure even deaf people would buy it :-).
__________________
maemo blog
 

The Following 2 Users Say Thank You to fpp For This Useful Post:
fpp's Avatar
Posts: 2,853 | Thanked: 968 times | Joined on Nov 2005
#55
Status report on my call(s) for help... :-)

No sign of life on the Rockbox thread. Seems abandoned for good :-(

However, some people seem to follow Planet Maemo still.
Over the weekend I wrote a blog post about this project which was syndicated there.

Today I got some comments, one of which :

- was not spam :-)

- had some very interesting info and suggestions by a developer from Igalia who seems to know
quite a bit about the Maemo sound system...

Read it here and see what you think of his advice:
http://fredp.lautre.net/blog/2012/03...-music-player/
__________________
maemo blog
 

The Following 2 Users Say Thank You to fpp For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#56
Interesting. so, 2 ways of doing what we want to achieve:

1. Make pulseaudio output to our external card (should be trivial, yet no one know how to do it up to date...)

2. Use mafw-gstreamer code (which is open, as it seems) and do little tweak, to change it's output. Should be quite easy for coders. 2a. Prepare way to change them on fly - "proxy" that igala suggested (NFC what he mean exactly), or script to switch between versions with ease.

Personally, I would prefer to use clean option 1, if someone would be able to actually achieve it Yet, I must agree, that option 2 would use less CPU, due to omitting pulseaudio (although, I think difference would be neglible). More messy, as it included switching plugins on the fly (I wonder if it would be possible without reboots?), or some kind of proxification.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 2 Users Say Thank You to Estel For This Useful Post:
Posts: 18 | Thanked: 38 times | Joined on Jan 2012
#57
Originally Posted by fpp View Post
Interesting find... although of course it just means that if we could use the DSP *and* bypass PA, then we would use even *less* CPU cycles that the stock media player :-)
Also, CPU decoding is very dependent on the codec type and its settings : flac, mp3 and ogg will have different CPU usage patterns for example. And also flac 0 vs. flac 8, or mp3 128k vs. mp3 320 vs.mp3 VBR0, etc
I wonder (but this is just a wild guess) if DSP decoding would prove less variable.
By the way, what are you trying to achieve?
If the goal is lower power consumption, then CPU load indicator is not the best thing to look at. Because ARM core is not the only consumer, not to mention linux cpu load statistic won't give a complete picture of ARM core usage.
 

The Following User Says Thank You to kirillkk For This Useful Post:
Posts: 72 | Thanked: 184 times | Joined on Apr 2011 @ Germany
#58
Another half-useful result of my experiments:

Looking at the code of the recaller widget, one sees that it is possible to use the output of a pulse sink (at least the internals) as a gstreamer source and therefore play it back via usb:

Code:
gst-launch pulsesrc device=sink.hw0.monitor ! audioconvert ! audioresample ! alsasink device=hw:1,0
This plays back the output of the internal music player (perhaps any sound application that uses pulseAudio) through usb. There are two pitfalls:
  • The normal output is not muted (minor problem I would guess and maybe solvable with alsamixer - as it should work on a lower level than pulse audio
  • The audio stutters a lot (at least for me) - making this unusable for anything serious

Could someone try the above command on his/her setup? My device is not overclocked, and maybe it depends also on the external hardware. Be warned though, I got occasional reboots.

//EDIT:

To try this, just type the above in an xterm and play something back through the stock media player.

Last edited by Oblomow; 2012-04-03 at 11:51. Reason: added more detailed information
 

The Following 2 Users Say Thank You to Oblomow For This Useful Post:
fpp's Avatar
Posts: 2,853 | Thanked: 968 times | Joined on Nov 2005
#59
Originally Posted by kirillkk View Post
By the way, what are you trying to achieve?
If the goal is lower power consumption, then CPU load indicator is not the best thing to look at. Because ARM core is not the only consumer, not to mention linux cpu load statistic won't give a complete picture of ARM core usage.
My modest goal would be to achieve decent battery life if we ever get this to work, given that h-e-n will already be gobbling down a good deal of juice :-)

I believe you, but I can't help thinking that if people put DSPs in mobile device, and stock media player uses it, there must be a reason, and something to gain :-)
__________________
maemo blog
 

The Following User Says Thank You to fpp For This Useful Post:
fpp's Avatar
Posts: 2,853 | Thanked: 968 times | Joined on Nov 2005
#60
Originally Posted by Oblomow View Post
To try this, just type the above in an xterm and play something back through the stock media player.
I will try it of course, but what a really strange command line !

Are those separators really exclamation marks ? :-)

I also have my doubts about the "audioconvert ! audioresample" parts on there, are they really necessary ?
I don't like the idea of the signal being reprocessed (what for ?), and it could possibly be the cause for the stuttering...
__________________
maemo blog
 

The Following 2 Users Say Thank You to fpp For This Useful Post:
Reply

Tags
h-e-n, usb audio


 
Forum Jump


All times are GMT. The time now is 23:37.