| 1 |
MediaInfo class |
| 2 |
=============== |
| 3 |
|
| 4 |
It might be nice to have a class that gives information about MediaSource |
| 5 |
objects without having to use MediaObject for it. Something like QFileInfo for |
| 6 |
QFile. MediaObject could also return a list of MediaInfo objects for all the |
| 7 |
MediaSource objects in the queue. |
| 8 |
|
| 9 |
Rationale: The app then can get info about length and substreams so that it can |
| 10 |
set up everything correctly for the next "file" in the queue. |
| 11 |
|
| 12 |
|
| 13 |
- on hotplug of a USB audio/video device: |
| 14 |
1. If the device is plugged in for the first time |
| 15 |
Check whether the backend now provides new device selections. If yes, open |
| 16 |
up central config with the page that allows selection of the default |
| 17 |
devices. Tell the user what new options are available. |
| 18 |
Allow the user to set preference of devices: If device USB-Headset is |
| 19 |
available use that, else use builtin speakers. |
| 20 |
|
| 21 |
device info persistance |
| 22 |
========================= |
| 23 |
On device selections: should the user be presented with options that are |
| 24 |
currently not available? It might actually be confusing to select a device that |
| 25 |
is not usable at the moment. |
| 26 |
|
| 27 |
Some situations: |
| 28 |
(device A is always available) |
| 29 |
- user plugs device B |
| 30 |
- selects device B as default |
| 31 |
next day: device B unplugged |
| 32 |
- phonon falls back to device A as B is not available and shows a passive popup |
| 33 |
informing the user about the fallback |
| 34 |
- user opens config dialog |
| 35 |
- device B still shows up as default |
| 36 |
- selects device A, closes dialog |
| 37 |
- opens dialog again |
| 38 |
- device B is gone... |
| 39 |
- user plugs device B |
| 40 |
- device B reappears |
| 41 |
|
| 42 |
The Backend has to provide the information about devices. Those can map directly |
| 43 |
to hardware or a soundserver or some other virtual device. The Backend has to |
| 44 |
have some unique identifier. For example the ALSA devices could be identified |
| 45 |
using the ALSA device names (either hw:0, hw:1 or aliases from asoundrc). OSS |
| 46 |
devices could be identified using /dev/dsp, /dev/dsp1 and so on. |
| 47 |
=> the backend internal uid is a string |
| 48 |
In the Frontend all that is needed is a name and a description of the device |
| 49 |
(both translated to the current locale) and a unique identifier to talk to the |
| 50 |
backend. This identifier could be the same as used internally by the Backend, |
| 51 |
but doesn't have to be. |
| 52 |
|
| 53 |
"lowlevel" audio I/O |
| 54 |
====================== |
| 55 |
ByteStream is a buffered stream, and as therefore completely useless for cases |
| 56 |
where an application wants to write audio data to the soundcard/-system with low |
| 57 |
latency. |
| 58 |
=> PcmInStream and PcmOutStream |
| 59 |
|
| 60 |
|
| 61 |
============================================================================ |
| 62 |
= Ideas for "useless but nice" things (until somebody can convince me that = |
| 63 |
= they're useful) = |
| 64 |
============================================================================ |
| 65 |
|
| 66 |
Video Output |
| 67 |
============== |
| 68 |
Add another VideoOutput that can be used directly with QGraphicsView by creating |
| 69 |
a QGraphicsItem subclass. |
